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Using  the  Vienna  Development  Method  (VDM) 
To  Formalize  a  Communication  Protocol 


Abstract:  The  Vienna  Development  Method  (VDM)  is  based  upon  iterative  refinement  of 
formal  specifications  written  in  the  model-oriented  specification  language,  Meta-IV.  VDM 
is  also  an  informal  collection  of  experiences  in  formal  specification  within  several  appli¬ 
cation  domains.  This  paper  provides  an  example  of  how  VDM  might  be  used  in  the  area 
of  communications,  a  new  domain  for  VDM. 


\!  1.  Introduction 

y 

The  purpose  of  this  document  is  to  serve  as  an  introduction  to  certain  specification  tech¬ 
niques  and  the  specificatior^iariguage  (Meta-iV)  of  the  Vienna  Development  Method  (VDM) 
and  to  further  extend  the  use  of  VDM  by  a{:^lying  it  within  a  new  domain.  VDM  has  been 
applied  to  the  specification  of  a  communication  protocol.  The  protocol  is  one  used  for  the 
communication  between^  inertial  navigation  system  (INS)  and  an  external  computer  (EC), 
ae-deftneitfin^^this  protocol  was  chosen  because  it  is  a  new  application  area  for  VDM, 
and  it  is  an  infe^^ral  part  of  an  existing  project  at  the  SEI.  The  Real-Time  Embedded  Sys¬ 
tems  Testbed  (REST)  Project  is  implementing  the  protocol  as  part  of  an  INS  simulator  sys¬ 
tem  that  is  being  developed  to  investigate  the  use  of  Ada  for  embedded  systems.  ] 

The  formal  specification  is  expressed  using  the  specification  language  Meta-])Aof  VDM  [2]. 
Knowledge  of  the  specification  language  is  not  a  prerequisite  for  reading,thfs  document,  as 
we  will  introduce  all  the  necessary  parts  of  the  language  in  a  suteequeht  section. 

Chapter  2  provides  an  introduction  to  communication  protocols  and  VDM.  It  contains  a  brief 
overview  of  the  protocol  defined  in  [14]  and  introduces  the  central  ideas  of  VDM.  The  for¬ 
malization  of  key  concepts  in  the  protocol  is  discussed.  The  formal  specification  is  intro¬ 
duced  by  presenting  the  necessary  parts  of  Meta-lV,  providing  examples  of  the  use  of  Meta- 
IV,  and  describing  particular  techniques  and  conventions  used  in  the  specification. 

Chapters  3  through  7  contain  the  formal  specification  itself.  The  model  consists  of  type 
equations  that  define  the  objects  to  be  used  in  describing  the  communication  protocol,  and 
functions  that  formalize  the  protocol  by  operating  on  those  objects. 


Chapter  8  summarizes  the  area  of  formal  specification  of  communication  protocols  and  re¬ 
lates  our  work  to  previous  work  in  the  area.  The  document  closes  with  Chapter  9.  suggest¬ 
ing  ideas  for  future  work. 
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2.  Communication  Protocols  and  VDM 


2.1.  Communication  Protocols 

A  communication  protocol  is  defined  in  [15]  as: 

1 .  Data  communication.  A  formal  set  of  conventions  governing  the  format  and 
relative  timing  of  message  exchange  between  two  communications  terminals. 

2.  Software.  (A)  A  set  of  conventions  or  rules  that  govern  the  interaction  of  proc¬ 
esses  or  applications  within  a  computer  system  or  network.  (B)  A  set  of  rules 
that  govern  the  operation  of  functionad  units  to  achieve  communication. 

3.  Station  control  and  data  acquisition.  A  strict  procedure  required  to  initiate 
and  maintain  communication. 

The  specific  communication  protocol  described  in  [14]  defines  rules  for  communication  be¬ 
tween  an  inertial  navigation  system  (INS)  and  an  external  computer  (EC).  The  INS  receives 
information  from  a  number  of  sensors  that  record  data  about  a  ship  and,  using  that  data, 
determines  its  current  velocity  and  position.  The  protocol  dictates  the  procedures, 
periodicity,  and  format  for  sending  data  to  an  EC.  It  defines  how  to  establish  communication 
when  requested  by  the  EC  and  how  messages  are  transferred.  It  defines  what  each  of  the 
two  computers  must  do  in  case  of  detected  errors  (receiving  "wrong"  input  from  the  other 
computer).  Finally,  it  defines  how  the  EC  can  tenninate  communication. 

As  specified  in  [14],  communications  are  performed  over  a  16-bit  interface.  In  addition,  each 
sixteen  bit  quantity  is  either  an  external  function  (EF)  or  data.  The  EF  codes  are  used  to 
control  the  communication  protocol  and  to  delimit  messages.  The  code  identifiers  and  their 
functions  are  listed  in  Table  2-1.  Note  that  not  all  the  EF  codes  defined  in  [14]  are  used  in 
the  INS  simulator  system.  Consequently,  the  specification  limits  itself  to  those  in  Table  2-1 . 

The  full  range  of  message  types  and  formats  is  defined  in  [14].  The  INS  simulator  appli¬ 
cation  uses  only  some  of  these  message  types.  The  message  types  that  may  be  trans¬ 
mitted  to  the  EC  are  listed  in  Table  2-2.  The  message  types  that  may  be  received  from  the 
EC  are  listed  in  Table  2-3. 
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Code  Function 

ACK  Acknowledge  (i.e.,  received  a  valid  message) 

ATTN  1  Indicate  a  time-out  condition 

ATTN2  Enable  communications 

ATTN4  Disable  communications  (sent  by  EC  only) 

EOM  End  of  message 

NAK  Not-Acknowledge  (i.e..  received  an  incomplete  or  invalid 

message) 

NRTR  Not  ready  to  receive 

RTR  Ready  to  receive 

SOTM  Start  of  test  message 

SOM  Start  of  message 


Table  2>1 :  External  Function  (EF)  Codes 


lessaae  Type 
Test  Message 

Time  and  Status  Data  Message 
Attitude  Data  Periodic  Message 
Navigation  Data  Periodic  Message 


Message  Contents 

Contains  a  fixed  pattern  to  allow  checking  of  com¬ 
munications. 

Cont^ns  fields  for  the  time-of-day  and  various 
status  codes. 

Contains  various  fields  of  numerical  data  pertaining 
to  the  (simulated)  ship  motion. 

Contains  fields  of  numerical  data  pertaining  to  the 
(simulated)  ship  motion. 


Table  2-2:  Messages  to  EC 
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Message  Type 
Test  Message 
Select  Data  Message 


Message  Contents 

Contains  a  fixed  pattern  to  allow  checking  of  communications. 

Contains  fields  to  select/deselect  the  periodic  messages  that 
may  be  sent  from  the  INS. 

Table  2*3:  Messages  from  EC 


2.2.  Formal  Specification  Using  VDM 

VDM  is  a  formal,  mathematically  oriented  method  for  specification  of  systems  and  devel¬ 
opment  of  software.  In  general,  formal  specification  languages  fall  into  two  classes:  al¬ 
gebraic  languages  and  model-oriented  languages.  VDM  is  a  model-based  method.  Its  main 
idea  is  that  of  giving  descriptions  of  software  systems  and  other  systems  as  models. 
Models  are  specified  as  objects  and  operations  on  objects,  where  the  objects  represent  in¬ 
put,  output,  and  internal  state  of  the  system.  Classes  of  objects  are  explicitly  defined  as 
so-called  "domains,”  which  are  like  types  in  a  programming  language.  Model-based  meth¬ 
ods  differ  from  algebraic  and  other  formal  methods  in  that  they  explicitly  define  the  types  of 
objects  of  concern  and  utilize  primitive,  predefined  operations  in  defining  higher-level  opera¬ 
tions. 

VDM  encourages  layered,  top-down  development  of  systems,  based  on  use  of  abstraction 
at  the  uppermost  levels  of  system  description  (see  [16]). 

In  this  document,  we  do  not  explore  the  stepwise  refinement  aspects  of  VDM.  Our  model 
constitutes  only  a  requirements  specification  that  may  be  used  as  a  starting  point  for  imple¬ 
mentation. 

At  the  highest  level,  a  specification  is  typically  given  as  a  rather  abstract  model.  The  objects 
do  not  capture  details  of  representation;  they  are  restricted  to  capturing  only  properties  nec¬ 
essary  for  expressing  the  essential  concepts  of  the  operation  of  the  intended  software  sys¬ 
tem. 

Within  a  number  of  specific  application  areas,  such  as  programming  language  semantics  [3], 
compiler  construction  [20],  and  data  bases  [4],  standard  VDM  models  and  guidelines  for  de¬ 
velopment  exist. 

Meta-IV,  which  is  the  specification  language  of  VDM,  is  used  for  expressing  the  models  [2]. 
The  models  are  defined  using  a  number  of  type  definitions  (for  the  objects)  and  function 
definitions  (for  the  operations).  This  is  different  from  the  algebraic  approach  to  specification, 
where  the  models  (algebras)  are  implicitly  defined  by  the  properties  captured  in  the  axioms 
of  the  algebraic  specifications. 
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Meta-IV  is  aimed  at  supporting  abstraction  in  writing  specifications.  Abstraction  is  obtained 
through  mathematical  concepts,  such  as  sets  and  functions,  rather  than  through  the 
mechanisms  offered  by  any  particular  implementation  language.  The  abstraction  provided 
by  Meta-IV  is  not  oriented  toward  any  particular  application  area,  but  rather  offers  a  set  of 
mathematically  based  primitives  that  allow  the  construction  of  application-specific  models. 

When  using  VDM,  an  abstract  model  traditionally  contains  the  following  components: 

•  Semantic  domains.  Types  that  define  the  objects  to  be  operated  on. 

•  Invariants.  Functions  that  limit  the  set  of  objects  defined  by  the  semantic 
domains  by  defining  a  set  of  conditions  (Boolean  functions). 

•  Syntactic  domains.  Types  that  define  a  "language”  in  which  to  express  com¬ 
mands  for  manipulating  the  objects  defined  by  the  semantic  domains. 

•  Well-formedness  conditions.  Functions  that  define  when  the  commands 
(defined  by  the  syntactic  domains)  have  a  well-defined  effect. 

•  Semantic  functions.  Functions  that  define  the  effect  of  commands  on  the  ob¬ 
jects  defined  by  the  semantic  domains. 


2.3.  Formalization  of  the  Communication  Protocol 

2.3.1.  An  Outline  of  the  Basic  Approach  Used 

Communication  protocols  are  not  one  of  the  areas  for  which  well-established  VDM  models 
or  guidelines  exist.  Mechanisms  for  specifying  communication  protocols  using  other  tech¬ 
niques  exist.  Probably  the  most  well-established  technique  is  the  use  of  some  form  of  a 
state  machine.  Obviously,  one  could  "mimic"  sudi  a  state  machine  using  a  VDM  model,  but 
we  would  like  to  represent  the  protocol  at  a  level  that  is  closer  to  the  original  informal  docu¬ 
mentation,  i.e.,  without  identifying  "states"  of  the  communicating  components  but  only  speci¬ 
fying  "the  communication  itself." 

Previously  combinations  of  Meta-IV  and  Hoare’s  CSP  [13]  have  been  used  to  describe  sys¬ 
tems  that  involve  communication.  Our  specification  uses  Meta-IV  in  its  "pure"  form  without 
any  extensions. 

The  definition  of  communication  protocols  given  in  Section  2.1  says  that  a  communication 
protocol  is  a  set  of  rules  or  conventions  governing  information  exchange,  including  the  rela¬ 
tive  timing  of  information  exchanges.  We  will  refer  to  exchange  of  information  as  an  "event." 
and  rules  related  to  event  ordering  and  their  relative  timing  can  be  seen  as  defining  proper 
sequences  (or  lists)  of  such  events.  The  order  in  which  the  events  occur  in  the  list  reflects 
the  order  in  which  they  happen.  Hence,  one  way  of  formalizing  a  communication  protocol  is 
to  define  all  possible  event  sequences  that  are  defined  by  the  protocol.  This  is  similar  to 
formalizing  the  static  semantics  of  a  programming  language  by  defining  all  legal  programs 
that  can  be  written  in  the  language  [21].  Obviously,  the  set  of  event  sequences  defined  by 
the  protocol  Oust  like  the  set  of  all  legal  programs)  is  infinite  and  cannot  be  defined  by 
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simple  enumeration.  Instead  the  set  is  defined  by  first  characterizing  the  set  of  all  possible 
event  sequences,  while  ignoring  the  ordering  and  timing  constraints  defined  by  the  rules  of 
the  protocol  (like  defining  a  context  free  grammar  for  a  programming  language),  and  then 
restricting  that  set  through  Boolean  functions  (predicates)  that  define  whether  a  given  list  of 
events  is  in  accordance  with  the  protocol  (like  defining  the  context  conditions  of  a  program¬ 
ming  language). 

The  conditions  expressed  by  the  Boolean  functions  are  to  be  obeyed  by  any  event  se¬ 
quence  of  arbitrary  length.  When  looking  at  each  such  individual  sequence,  the  rules  of  the 
protocol  can  be  divided  into  two  groups:  one  expressing  whether  each  event  in  the  se¬ 
quence  occurs  in  the  right  context  (defined  by  events  preceding  the  one  in  question);  and  a 
second  expressing  whether  the  sequence  is  complete,  meaning  that  no  additional  events 
are  required  to  happen. 

Some  of  the  specific  problems  associated  with  formalizing  the  communication  protocol  are 
that  a  communication  channel  is  generally  not  error-free,  and  the  formal  specification  must 
be  able  to  capture  that  the  information  sent  from  one  component  in  the  system  is  not  neces¬ 
sarily  identical  to  that  received  by  the  other  component.  The  communication  protocol  de¬ 
scribes  how  to  detect  and  handle  certain  errors.  The  communication  protocol  also  includes 
time  constraints  on  the  behavior  of  the  components.  Hence,  the  notion  of  "time"  must  be 
part  of  the  model.  Moreover,  the  system  defined  by  the  communication  protocol  does  not 
exist  in  isolation.  It  has  an  environment  that  affects  and  is  affected  by  the  communication. 
For  this  particular  protocol,  the  environment  includes  (at  least)  the  operators  of  the  INS  and 
the  EC. 

2.3.2.  Modeling  Communication  Errors 

The  protocol  as  defined  in  [14]  prescribes  the  correct  communication  behavior  of  the  INS 
and  the  EC,  but  this  includes  specifying  the  behavior  of  the  INS  in  cases  where  it  receives 
messages  that  are  "out  of  sequence,"  for  example,  due  to  errors  on  the  communication  line 
or  incorrect  behavior  of  the  EC. 

The  fact  that  the  messages  received  are  not  necessarily  those  sent  (due  to  possible  trans¬ 
mission  errors)  means  that  the  transfer  of  a  message  may  be  seen  differently  by  the  INS 
and  the  EC.  These  two  "perspectives"  on  the  events  lead  to  the  introduction  of  two  se¬ 
quences  of  events:  one  for  events  as  seen  at  the  INS  (e.g.,  sending  to  or  receiving  from  the 
EC),  and  a  similar  one  for  events  as  seen  at  the  EC.  Such  a  model  is  appealing  because 
the  correctness  of  the  behavior  of  the  INS  and  EC  is  decided  by  how  each  sees  the  world 
(not  by  what  the  other  one  actually  did;  transmission  errors  may  introduce  differences).  This 
approach  also  captures  situations  where  a  message  is  lost  by  the  channel  or  spontaneously 
created  (seen  by  the  receiver)  due  to  noise  on  the  channel. 

From  the  point  of  view  of  the  process  issuing  an  event,  such  an  event  is  either  correct  or 
Incorrect  according  to  the  protocol,  given  the  history  (sequence)  of  previous  events  (issued 
as  well  as  received).  Received  events,  however,  are  either  expected  or  unexpected  (but 
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never  incorrect,  since  out-of*sequence  events  must  be  reacted  to  in  a  manner  prescribed  by 
the  protocol).  Hence,  unexpected  events  capture  messages  that  have  been  distorted  due  to 
errors  on  the  communication  line  or  an  incorrect  behavior  of  the  issuing  component.  The 
relation  between  correct  and  expected  events  is  that  events  that  are  correct  for  the  issuer 
(given  a  particular  history)  are  expected  by  the  receiver  (under  the  same  circumstances). 

2.3.3.  Modeling  ’Time" 

The  concept  of  a  process  being  willing  to  wait  only  a  certain  amount  of  time  (and  then 
"timing-our)  for  a  response  (event)  is  mentioned  several  times  in  [14].  One  way  of  formaliz¬ 
ing  "time-outs”  is  to  associate  a  time-stamp  with  each  event,  and  then  let  conditions  that 
relate  to  time-outs  interrogate  that  information  and  let  conditions  related  to  other  parts  of  the 
protocol  ignore  the  timing  information. 

Time-stamps  allow  for  the  specification  of  correct  behavior  based  upon  the  relation  between 
time-stamps  associated  with  certain  events.  A  possible  alternative  is  to  introduce  a  timer 
and  perhaps  a  clock  into  the  formal  specification.  Explicitly  including  timers  and  clocks  is  a 
technique  sometimes  used  in  formal  descriptions  of  concurrent  systems  for  defining  such 
events  [17].  Using  a  timer  leads  to  the  introduction  of  explicit  timer  events  such  as  a  "start 
timer"  and  a  "time-out"  event.  But  these  events  are  not  described  by  the  protocol;  instead, 
the  protocol  describes  events  that  are  caused  by  a  time-out.  Hence,  in  the  context  of  this 
communication  protocol,  introducing  such  events  seems  to  move  the  formal  description  from 
the  problem  domain  in  the  direction  of  a  "solution."  This  led  us  to  use  time-stamps  in  the 
model. 

2.3.4.  The  Environment  and  Its  Impact  on  the  Model 

According  to  [14],  the  INS  alerts  the  operator  in  case  certain  types  of  errors  are  detected.  In 
our  model,  events  such  as  alerting  the  operator  are  called  non-communication  events,  i.e., 
they  do  not  reflect  the  transfer  of  a  message  between  the  INS  and  the  EC. 

Informally  speaking,  the  initiative  to  communicate  (enable  communication.  Initiate  the  send¬ 
ing  of  periodic  messages,  etc.)  belongs  to  the  EC,  and  [14]  does  not  define  what  causes  the 
EC  to  take  such  Initiatives.  In  reality,  however,  this  does  not  mean  that  the  EC  arbitrarily 
makes  such  decisions;  rather  the  EC  responds  to  requests  from  an  operator  or  potentially 
another  environmental  influence.  Hence,  specific  EC-operator  non-communications  events 
are  introduced  into  the  model  to  reflect  the  operator’s  requests  (like  "Enable 
Communication").  Thus  the  "arbitrary"  decisions  become  a  part  of  the  environment  of  the 
system  rather  than  a  part  of  the  system  itself. 
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2.3.5.  Periodic  Message  Transfers 

The  attitude  and  navigation  messages  sent  from  the  INS  to  the  EC  are  "periodic”  messages. 
In  [14]  this  is  described  by  phrases  like  "It  is  transmitted  every  61.44  ms"  (for  attitude  mes¬ 
sages,  [14]  pg.  8-36),  and  "This  message  is  transmitted  every  983.04  ms"  (for  navigation 
messages,  [14]  pg.  8-24).  There  are  at  least  ttiree  possible  interpretations  of  periodicity: 

1 .  Within  each  designated  time  interval,  a  message  of  the  relevant  type  must  be 
transmitted  exactly  once,  and  tire  transmission  must  be  completed  before  the 
start  of  the  next  interval. 

2.  The  messages  are  transmitted  with  a  fixed  time  interval  elapsed  from  the  start 
of  one  such  message  transfer  sequence  to  the  next. 

3.  Fixed  inten/al  for  the  data  component  of  the  transfer. 

The  first  interpretation  is  the  one  used  in  describing  certain  real-time  scheduling  algorithms 
like  the  rate-monotonic  scheduling  algorithm  [18].  On  the  other  hand,  the  second  or  third 
interpretation  should  apply  if  the  receiving  component  (here  the  EC)  in  its  use  of  the  data 
relies  on  receiving  data  with  fixed  inter-arrival  times.  This  is,  however,  not  specified  in  [14]. 

Moreover,  since  the  transmission  of  a  periodic  message  consists  of  a  number  of  lower-level 
transmissions,  namely  SOM,|g3  RTR^^s  <the  data>|f^3  EOM„^3  (subscripts  indicating  the  is¬ 
suing  component)  and  a  first  failed  transmission  will  lead  to  a  retransmission,  it  is  not  clear 
from  [14]  where  the  periodicity  requirement  applies. 

In  our  model,  interpretation  1  is  used  with  the  additional  decision  that  the  time  requirement 
applies  to  the  EOM||^3  that  marks  the  end  of  the  message.^ 

2.4.  Introduction  to  the  Formal  Model 

In  the  first  part  of  this  section  the  basics  of  Meta-tV  are  introduced,  which  include  primitive 
and  composite  types,  type  constructors,  functions,  and  expressions.  The  following  section 
broaches  the  topic  of  constructing  Meta-IV  functions  by  combining  the  aforementioned  con¬ 
structs.  In  addition,  several  techniques  that  were  employed  in  this  specification  that  capi¬ 
talize  on  domain  knowledge  to  reduce  specification  complexity  will  be  discussed  Finally  a 
list  of  the  conventions  used  in  this  specification  will  be  presented. 

2.4.1.  The  Specification  Language 

This  section  defines  those  parts  of  Meta-IV  that  are  used  in  the  formal  model;  for  a  complete 
definition  of  Meta-IV,  see  [2].  The  use  of  each  relevant  language  construct  is  illustrated  by 
examples  drawn  from  the  format  model  presented  in  Sections  3  to  7. 


could  bo  intorosting  at  a  later  time  to  see  how  easily  the  formal  model  can  be  changed  to  reflect  inter¬ 
pretation  2  or  3  instead. 
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2.4.1 .1.  Types 

Meta-IV  offers  a  number  of  primitive  as  well  as  composite  types. 

The  primitive  types  used  are:  natural  numbers  (NO  and  N1).  Booleans  (BCXDL),  arbitrary 
non-decomposable  text  strings  (QUOT).  and  special  simple  values  (TOKEN).  Each  of  these 
is  characterized  in  the  following. 

•  NO  and  N1.  The  objects  are  the  natural  numbers  (including  and  excluding  0). 

The  numeric  literals  as  well  as  the  traditional  arithmetic  and  relational  operators 
are  predefined  operations. 

•  BOOL.  The  objects  are  the  Boolean  values.  The  Boolean  literals  (true  and 
false),  and  the  logical  operators  a  (and),  v  (or).  (not),  and  z>  (implication),  as 
well  as  comparison  (»  and  *).  are  pr^efined.  The  logical  operators  are  not 
commutative.  This  means  that,  for  example,  a  a  b  is  defined  as:  jf  a  then  b  else 
false.  The  non-commutivity  of  a  is  utilized  in  our  model,  wh^eas  the  non- 
commutivity  of  v  is  not. 

•  QUOT.  The  objects  are  arbitrary  non-decomposable  text  strings.  Being  non- 
decomposable  means  that  no  operation  exists  for  extracting  parts  of  such  a 
string;  as  a  matter  of  fact  the  only  available  operations  are  the  literals,  which 
are  underlined  text  strings,  and  equality  (=)  and  inequality  (9^).  The  type  QUOT 
is  similar  to  set  types  in  Pascal  or  enumeration  types  in  Ada. 

•  TOKEN.  The  objects  are  simple  values  whose  representation  is  not  defined. 

No  literals  exist  for  this  type.  The  only  predefined  operations  are  equality  (-) 
and  inequality  {*). 

Based  on  the  above  primitive  types,  other  (composite)  types  can  be  defined.  The  following 
composite  types  are  used  in  the  model:  sets,  tuples,  and  trees.  Each  of  these  is  described 
below. 

•  Sets  of  values  of  another  type.  The  (postfix)  type  constructor  is  -set,  and  it  de¬ 
fines  the  new  type  to  consist  of  all  finite  sets  of  elements  of  the  argument  type. 

All  elements  in  a  set  are  different  and  they  are  not  ordered.  The  predefined 
operators  for  sets  include: 

1 .  Equality  and  inequality. 

2.  Set  object  constructors:  {e^.e2. ...  .e,^  defines  a  set  with  n  elements  e^ 
to  Op  (provided  that  all  the  e’s  are  different,  otherwise  the  resulting  set 
contains  each  (different)  element  exactly  once).  0  is  the  empty  set  with 
no  elements.  {F(i)  |  P(i)}  defines  a  set  whose  elements  are  defined  by 
F(i)  for  all  /  satis^ng  ^e  predicate  P(i)  (a  Boolean  function);  for  ex¬ 
ample,  {i**2 1  2  ^  i  ^  6}  is  {4,9,16.25.36}. 

3.  Set  membership:  The  operator  e  is  defined  for  each  set  type,  e  e  s  ex¬ 
presses  that  the  element  e  belongs  to  the  set  s  (the  value  of  the  expres¬ 
sion  e  €  8  is  tive  if  e  belongs  to  s,  and  false  otherwise);  for  example 
5  e  {5,2,1}.  Similarly,  e  e  s  is  defined  as:  e  does  not  beiong  to  s.  Hence, 
for  exaniple,  5  c  {5,2,1}  is  false. 

4.  Subset  relation:  si  c  82  says  that  si  is  a  proper  subset  of  s2.  i.e.,  all 
elements  of  si  are  also  elements  of  82,  but  there  is  at  least  one  element 
of  s2  that  is  not  an  element  of  si ;  for  example.  {2,1}  c  {1,2,5}. 
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•  Tuples  (or  sequences)  of  values  of  another  type.  The  (postfix)  type  constructor 
is  *.  and  it  defines  the  new  type  to  consist  of  all  finite  sequences  of  values  of  the 
argument  type  including  the  empty  sequence  containing  no  values.^  The  impor¬ 
tant  characteristic  of  a  tuple  is  that  the  elements  are  ordered,  so  that  one  can 
refer  to  the  i'th  element.  The  following  operations  are  predefined  for  tuples: 

1 .  Equality  and  inequality. 

2.  Tuple  object  constructors:  <e^,e2. ...  .en>  defines  a  tuple  of  length  n  with 
elements  e^  to  e^.  o  is  the  empty  tuple  vwth  no  elements. 
<F(i)  I  n  ^  i  ^  m  A  P(i)>  defines  a  tuple  whose  elements  are  defined  by 
F(i)  for  /  between  n  and  m  inclusive  and  satisfying  the  predicate  P(i)  (a 
Boolean  function).  For  example,  <i**2  j  2  ^  i  ^  6  a  ls_Even(i)>,  where 
ls_Even  is  a  user  defined  predicate  with  the  obvious  definition,  is 
<4,16,36>.  Note  that  /  does  not  define  the  actual  index  values  in  the 
resulting  tuple;  the  index  values  are  always  from  1  the  the  length  of  the 
tuple. 

3.  Concatenation:  t1  ^  t2  is  the  tuple  resulting  from  concatenating  two 
tuples  t1  and  t2;  for  example  <1,5>  <2,1>  is  <1,5,2,1>. 

4.  Extraction  operations:  hd  t  yields  the  first  element  in  (or  head  of)  the 
tuple  t  (^  <5,2,1  >  is  5).  and  tj  t  yields  the  remaining  part  (or  tail)  of  the 
tuple  t  (tl  <5,2,1>  is  <2,1>).  Both  these  operations  are  partial  \n  that  they 
are  not  defined  for  empty  tuples,  len  t  is  the  length  of  a  tuple  t 
(len  <5,2,1  >  is  3).  ind  t  yields  the  set  of  indices  for  t  (the  values  from  1 
to  lent).  For  example  ind  <5,2,1  >  is  (1,2,3.) 

•  Named  trees^  (or  cartesian  products)  containing  values  of  other  types.  A  tree  is 
characterized  by  the  types  of  its  component  values.  All  values  of  a  particular 
tree  type  have  the  same  number  of  components  (as  opposed  to  tuples  where 
the  number  of  components  may  vary).  Trees  are  similar  to  record  types  in  pro¬ 
gramming  languages.  The  following  operations  are  predefined  for  trees: 

1 .  Equality  and  inequality.  Two  named  trees  are  equal  only  if  they  have  the 
same  name  and  the  values  of  corresponding  components  are  identical. 

2.  Tree  object  constructors:  Given  a  tree  type  defined  by  A  ::  B  C,  one  can 
construct  ot^ects  of  type  A  by  mk-A(b,c),  where  b  and  c  are  values  of 
the  types  B  and  C,  respectively.  For  example,  a  value  of 
type  D  ::  NO  BOOL  is  mk-D(5,true). 

3.  Selectors:  Given  the  above  definition  of  A  and  a  value  of  that  type,  one 
can  select  the  individual  components  by  s-  followed  by  the  type  name  of 
the  component  For  example  s-B(a)  yields  the  B-component  of  a  value 
"a"  of  type  A.  This  means  that  s-B(mk-A(b.c))  is  b. 


similar  type  oonstructor  exists  for  defining  non-empty  tuples.  The  oonstructor  is  ***,  but  it  is  not  used  in  this 
model. 

#  ^There  are  also  unnamed  trees,  but  «w  do  not  use  those. 
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2.4.1. 2.  Type  Equations  and  Abstract  Syntaxes 

The  types  of  objects  of  concern  in  the  model  are  defined  by  a  number  of  type  equations.  A 
type  equation  defines  a  type  in  terms  of  (other)  related  types  by  using  some  of  the  type 
constructors  defined  in  the  previous  section. 

A  number  of  mutually  dependent  type  equations  are  often  called  an  abstract  syntax,  and  the 
complete  set  of  type  equations  for  our  model  is  an  example  of  such  an  abstract  syntax.  A 
part  of  the  abstract  syntax  is  shown  below. 

Kvent__Ll8t  «  Event* 

Event  B  lMS_Bvent  |  EC_Event 

IHS_Xvent  :  IMS_Event_lnfo  Tlnie_StaiBp 

BC__Bvent  :  EC_Event_ln£o  Tlne_Staiip 

INS_Bvent_In£o  s  Conms_Bvent  |  ... 

BC_Bvent_In£o  «  Coans_Bvent  I  — 

Coama_Xvent  «  EF_Event  |  ... 

EF_Event  »  ATTH2  |  RTR  |  SOTM  |  ... 

Tlaie_Stasf>  «  MO 

The  first  type  equation  defines  event  lists  to  be  tuples  of  events. 

The  second  type  equation  defines  an  event  as  either  an  INS  event  or  an  EC  event.  The  type 
constructor  "I"  defines  the  new  type  as  consisting  of  values  from  either  of  the  involved  types. 
The  predefined  operations  are  those  of  the  constituent  types  and  apply  only  to  the  types  for 
which  they  are  defined. 

The  third  type  equation  is  an  example  of  a  named  tree  definition  which  defines  an  INS  event 
as  having  two  components:  INS  event  information  and  a  time  stamp  (both  defined  by  other 
type  equations). 

The  type  equation  for  EF_Event  defines  the  type  as  consisting  of  the  quotation  literals  (of 
type  QUOT)  present  on  the  right-hand  side. 

The  last  type  equation  defines  time  stamps  as  being  natural  numbers  (where  a  number 
represents  a  multiple  of  .01  milliseconds). 

An  example  of  a  value  of  type  Event_List  is: 

<  jj^>EC_Ev«nt  {ATTH2. 2) ,  ^>IMS_Bvent  (ATTM2, 10) , 

«Mc-EC  Evnt  (SOTM.  15) ,  ak-IMS  Evnt(RTR.30)  > 

This  describes  part  of  a  communication  where: 


# 


12 


CMU/SEka8-TR-26 


1 .  EC  sends  an  ATTN2  (at  time  2,  i.e..  at  time  0.02  ms) 

2.  INS  responds  (at  time  1 0) 

3.  EC  initiates  the  test  message  sending  sequence  (with  an  SOTM) 

4.  the  INS  says  that  It  is  ready  to  receive  (RTR)  the  test  message 

Each  type  equation  in  an  abstract  syntax  implicitly  defines  a  predicate  that  expresses 
whether  a  given  value  belongs  to  the  type.  Its  name  is  is-  followed  by  the  type  name.  In  the 
above  example,  predicates  such  as  is-iNS_Event  and  js-EC_Event  are  implicitly  defined. 
These  predicates  are  particularly  useful  for  types  such  as  INS_Event  and  EC.Event  that  are 
used  in  constructing  union  types  (using  |).  because  the  predicates  allow  one  to  know  the 
type  of  such  a  value;  in  the  example,  one  can  tell  whether  an  event  (value  of  type  Event)  is 
an  INS_Event  or  an  EC_Event. 

At  this  point  the  reader  should  be  able  to  understand  the  full  set  of  type  equations  of  the 
model  as  defined  in  Chapter  3. 

2.4.1 .3.  Functions 

A  function  is  characterized  by  its  name,  the  types  of  its  parameters  (if  any)  and  the  type  of 
its  result. 

The  general  scheme  for  defining  functions  is  illustrated  by  the  following  example: 
TijiMi__StaBf>8_NonJD«cr««sln9(«vent_llst)  « 

—  function  body 

type:  Event JId.st  -*  BOOL 

The  definition  gives  the  name  of  the  function,  here  Time_Stamps_Non_Decreasing.  It 
names  the  formal  parameter(s),  here  eventjist,  and  provides  a  body  that  defines  the  effect 
of  the  function.  It  defines  the  type  of  function,  in  this  case  a  function  from  values  of  type 
Event_Ust  to  values  of  type  BOOL.  is  a  type  constructor  that  defines  the  type  of  all 
(total)  functions  from  the  provided  parameter  type(s)  to  the  result  type.  Being  "total”  means 
that  the  function  returns  a  well-defined  value  for  all  possible  values  of  its  parameters.  Partial 
functions  may  have  undefined  result  values  for  some  subset  of  parameter  values.  Partial 
function  types  are  constructed  by  using  "  instead  of For  some  of  our  partial  func¬ 
tions  we  have  provided  a  so-called  "pre-condition,"  which  is  a  Boolean  expression  defining 
the  conditions  under  which  the  partial  function  is  guaranteed  to  yield  a  well-defined  result.  It 
is  written  as:  "gre;  some_boolean_exfX’ession"  immediately  following  the  type  of  the  partial 
function. 

In  some  cases  where  the  nature  or  role  of  one  (or  several)  parameter(s)  of  a  function  is 
different  from  the  rest,  the  function  may  be  defined  as  a  "curried"  function.  This  means  that 
instead  of  defining  the  type  of  function  as  one  of,  for  example,  two  parameters  like  "A  B 
C,"  its  type  may  be  defined  as  "A  -» (B  ->  C),"  which  says  that  when  one  applies  the  func- 
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tion  to  its  first  parameter  (of  type  A),  one  gets  a  (new)  function  from  the  remaining  parameter 
(here  of  type  B)  as  the  result.  As  an  example  consider: 

Event_Is_Correct_at_INS  (£_hi8tory>  (ijis_event)  = 

let  mk-INS  Event (event_ln£o, )  “  ins_event  in 
(is-Conma  Event (event_ln£o)  — > 

Con«ii8_Event_Ia_Correct_et_IKS  (£_hlstory)  (in8_event} , 

T  — > 

Hon_Coiiina_Event_I*_Corteet_at_INS  (£_hi8toxTf) ) 

type:  Event_List  (INS__Event  ->  BOOL) 

Here  the  first  parameter,  f_history,  provides  the  context  in  which  the  correctness  of  the  sec¬ 
ond  parameter.  ins_event,  is  expressed.  Hence,  Event_ls_Correct_at_INS,  when  applied  to 
a  history,  yields  the  function  that  expresses  the  correctness  of  INS  events. 

2.4.1. 4.  Meta-IV  Expressions 

In  addition  to  the  predefined  operations  and  user-defined  functions  described  in  the  previous 
sections,  some  Meta-iV  language  constructs  are  available  for  defining  the  body  of  functions. 
The  constructs  are;  let  constructs,  if  then  else  constructs,  McCarthy  conditionals,  cases  con¬ 
structs,  and  quantified  expressions.  They  are  introduced  below. 

•  1^  constructs;  A  let  construct  is  used  to  (locally)  introduce  an  identifier  within  a 
function  definition  and  to  bind  the  identifier  to  the  value  of  an  expression.  A  very 
simple  example  of  its  use  is: 

let  «  «  (1,3,8) 

—  some  expression  using  "a” 

Note  that  "a"  is  not  like  a  variable  in  a  procedural  programming  language  in  that 
one  cannot  update  "a"  once  it  has  been  bound  to  a  particular  value.  It  is  similar 
to  identifiers  used  in  purely  functional  programming  languages. 

A  let  construct  can  also  be  used  to  decompose  composite  values,  such  as 
trees,  and  give  names  to  their  components.  An  example  of  such  a  use  is: 

let  aJc-INS  Event  (event_in£o,  event_tiBie)  »  in8_event  ^ 

—  some  e:^pres8ion  using  event_ln£o  end  event_tiiiie 

where  ins_event  is  a  name  of  a  value  of  type  INS_Event  (maybe  a  parameter  of 
a  function),  and  eventjnfo  and  event_time  are  two  new  names  for  the  compo¬ 
nents  of  the  event.  This  decomposition  can  be  seen  as  an  alternative  to  the  use 
of  (several)  selectors  (see  Section  2.4.1. 1.).  In  case  a  particular  component  is 
not  used  in  the  following  expression,  it  need  not  be  named  on  the  left-hand  side 
of  the  let  construct  (leaving  the  space  blank  where  it  would  have  appeared). 

Another  form  of  let  construct  defines  the  selection  of  a  value  that  has  certain 
properties  (defined  by  a  predicate)  and  binds  it  to  a  name.  Its  general  form  is: 

1st  id  €  soma__s«t_or_typ«  s.t.  P(id)  ^ 

—  soma  sa^zsssion  using  id 


# 
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which  is  read:  "let  id  belonging  to  sonfie_set_or_type  be  such  that  P(id)  holds  in 
the  following  expression,"  where  some_set_or_type  is  an  arbitrary  set  or  type 
a  J  P  is  a  predicate  whose  value  (presumably)  depends  on  id. 

•  if  then  else  constructs:  Conditional  expressions  of  the  form: 

if  bool«an_ttzpr«sslon  then 
expresslonj^ 

else 

eapreaslon^ 

can  be  used  with  the  obvious  semantics.  Note  that  since  the  whole  construct  is 
an  expression,  both  expression^  and  expression2  (the  else-part)  must  be 
present. 

•  McCarthy  conditionals:  A  form  of  conditional  expression  that  allows  more  than 
two  alternatives  is  the  McCarthy  conditional.  Its  general  form  is: 

(boolean_eapresslonj^  — >  ezpresslonj^, 
(booleen_e3^resslon2  — >  eapreeslonj, 


(boolean_ei7re88ionQ  — >  eaqpreaalon^) 


The  value  of  such  an  expression  is  the  value  of  the  first  expression;  from  the  top 
whose  boolean_expressionj  has  the  value  true.  If  none  of  them  are  true  the 
value  is  undefined,  but  it  is  up  to  the  user  of  Meta-iV  to  ensure  that  this  does 
not  happen.  A  special  symbol  "T"  may  be  used  as  the  boolean_expression„  to 
catch  all  remaining  conditions. 

An  example  of  Its  use  in  the  model  is: 

Dat«_Bvent_l8_Correct_at_IHS  (f_hi8tory)  (ln8_«vant)  — 

Xat  aik-l'NS  Evant  (8v«nt  Info.  )  »  in8_«v«nt  ^ 

(  la-Taat  Mag  (•'v«nt_lnf o)  — > 

Ta8t_ll8g__l8_Cortact_at_IHS(f_hi8tory)  (avant_info) , 

l8-Tiaa  and  Statna  Mao  (av*nt_lnf o)  — > 

Il«a_and__Statu8_M8g_l8_Cott«ct_at_lMS  (f_hi8tory) , 

la-Attituda  Mao  (•▼•nt_iiif o)  — > 

Attituda__M8g_l8_Corract_at_lHS(f__hi8toty) 

(ev«nt  info) , 


ia-Maviqatlon  Mag  (aynt  inf o)  — > 

Marigat ion_M8g_la_Cotract_at_INS ( f_hiatory ) 

(•v«nt_info) , 

T  — >  falaa  ) 

tvpa;  Kv«nt_X>l8t  -»  (XNS_lv«nt  -»  BOOL) 
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The  McCarthy  conditional  uses  the  predefined  ]s-  operation  to  distinguish  the 
four  kinds  of  event  information  that  correspond  to  (potentially)  correct  data 
events  from  the  INS.  The  T"  covers  situations  where  the  event  information  is 
not  one  of  the  four  messages  explicitly  mentioned;  it  could  be  a 
Select_Data_Msg  or  an  Error  Data  Message:  see  Chapter  3. 


•  cases  constructs:  One  of  the  most  used  forms  of  conditional  expressions  in  the 
model  is  the  cases  construct.  Its  general  form  is: 

cases  select_expresslon: 

(e^resslon_ox_patternj^  — >  eaq»ressloii2 , 
(eaq>ression_or_pattexn2  — >  espresslon2, 


(expresslon_or_pattem^  — >  expression^) 


The  value  of  such  an  expression  is  the  value  of  the  first  expressionj  from  the  top 
whose  expression_or_pattemj  is  either  an  expression  whose  value  is  equal  to 
that  of  the  select_expression  or  a  pattern  that  matches  the  value  of  the 
select_expression.  Patterns  are  like  expressions  (typically  of  composite  types). 
The  difference  is  that  they  may  contain  unbound  identifiers  or  simply  empty 
spaces.  Unbound  identifiers  are  bound  by  ttie  pattern  so  that  they  may  be  used 
in  expression!  for  refem'ng  to  the  corresponding  components.  Empty  spaces 
are  used  for  components  that  are  of  no  importance  In  expressionj.  If  none  of 
the  expressions  or  patterns  matches  the  select_expresslon,  the  value  of  the 
whole  cases  expression  is  undefined,  but  it  is  up  to  the  user  of  Meta-IV  to  en¬ 
sure  that  this  does  not  happen.  A  special  symbol  T*  may  be  used  as 
expression_or_pattem„  to  catch  the  remaining  possible  values  of 
select_expression. 

An  example  of  its  use  in  the  model  is: 
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SOM_1 8_Corxect_1lhttn_PArlodlc_Msga_Are_Act  iv«t»d_«t_IMS 

(f_hl8tory)  (som_tiaie)  s 

cases  Muniber  Of  OutstandlnqSOMs  Sent_at_IMS (f_hlstory) : 
(0  — > 

cases  Last  n<2.f  history):  — 6. 3. 2. 2. a 

(  <  |^-EC_Bvent  (  ,  ) , 

ak-ntS  Kvent(ACK,  )  > 
true. 

<  nk-INS  Event  (ATTNl,  ) , 

sdc-IKS  Event (event  info,  )  >  — > 

is -Signal  to  INS  Operator (event_inf o) , 

<  ak-IMS  Event  (  ,  ) , 

atk-EC  Event  (ACK,  )  >  — > 

true, 

<  nk-EC  Event (ATTNl ,  ) , 

adc-EC  Event (event  info.  )  >  — > 

is-Signal  to  EC  Operator (event_in£o) , 

T  — > 

false  ) , 

1  — > 

cases  Irfist (f  history) : 

(  ^-INSjivent(e£,  )  — > 

e£  ■  ATTNl. 

«k-EC  Event  (ef.  ef^tiaw)  — > 

e£~" ■  ATTNl 

V 

ef  >  NAK 

V 

(  ef  B  NRTR  A 

soai_tiBa  -  ef_tlaw  >  Sleep_Period  } ) , 


T  — >  false  ) 

type;  Event_List  -»  (TlJBe_Staaf>  -*  BOOL) 


The  function  has  an  outer  cases  construct  governing  a  choice  that  depends  on 
the  number  of  currently  outstanding  SOMs  (0. 1  or  more).  If  the  number  is  0,  a 
cases  construct  utilizing  pattern  matting  is  used.  It  "looks"  at  the  last  two 
events;  If  they  match  one  of  the  four  explicit  patterns,  each  being  a  two- 
component  tuple,  the  value  of  the  corresponding  right-hand  side  is  the  function 
result.  Note  that  in  two  of  the  patterns  the  identifier  "eventjnfo"  occurs.  This  is 
an  unbound  identifier  that  is  being  bound  by  the  match  and  is  used  in  the  right- 
hand  side  expression.  If  the  number  of  outstanding  SOMs  is  1,  only  the  last 
event  is  of  interest,  and  the  condition  depends  on  whether  it  is  an  INS  event  or 
an  EC  event. 
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•Quantified  expressions:  Both  existential  and  universal  quantifications  are  used. 
Their  general  form  is: 

(3  id  e  aone_set_or_typ*)  (P  (id) ) 

(V  id  e  sataMi_a«t_or_typtt)  (P(id} ) 

which  are  read:  "there  exists  a  value  (id)  belonging  to  some_set_or_type  for 
which  P  holds’  and  “for  all  values  (kJ)  belonging  to  some_set_or_type  P  holds," 
where  P  is  a  predicate  that  depends  on  id.  In  both  expressions  more  than  one 
identifier  may  be  used  in  place  of  "id." 

An  example  of  its  use  in  the  model  is: 

Tlaa__^Stanpa_Non_Daeraaalng(avant_ll8t)  * 

(V  i,  j  €  ind  avant_liat) 

((i  <  j)  3 

(a-Tiiaa_Staap  (avant_ll8t  [1] }  S 

a-TliDa_StaiBp (avant_liat  [  j] ) ) ) 


type:  Syant_Llst  -»  BOOL 


The  function  uses  the  universal  quantifier  to  express  that  for  all  possible  pairs  of 
positions  in  an  event  list  (indices  in  a  tuple),  It  must  be  the  case  that  if  one  is 
lower  than  the  other,  then  the  time  stamp  associated  with  the  event  in  the  first 
position  is  less  than  or  equal  to  the  time  stamp  of  the  event  in  the  second  posi¬ 
tion. 


2.4.2.  Example  Meta-IV  Function  Descriptions 

Three  functions  from  the  formal  specification  are  discussed  in  detail.  Each  function  is  intro¬ 
duced  with  a  textual  description  of  its  purpose.  Each  of  its  constituent  parts  is  then  dis¬ 
cussed  to  illustrate  the  use  of  Meta-IV  in  formalizing  the  original  textual  description. 

2.4.2.1.  ACKJs_Correct_atJNS 

The  correctness  of  a  number  of  events  depends  only  on  a  few  of  the  immediately  preceding 
events  and  not  on  the  whole  history  of  earlier  events.  Moreover,  in  many  cases  the  actual 
time  at  which  those  events  occurred  is  unimportant.  The  following  function  illustrates  both 
aspects,  it  expresses  the  conditions  under  which  an  ACK||43  may  occur.  [14]  states  that  an 
ACK|ns  Is  issued  by  the  INS  after  it  has  received  a  valid  test  message  or  select  data  mes¬ 
sage  (both  are  of  the  type  Data.Message  in  our  model). 
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0.  ACK_l5_Correct_at_IMS  (£_hi8tory)  « 

cases  Last_n(2, £_hlstory) : 

(  <  aak-EC  Event (data  msq.  ),  — 6.3.2.2.C* 

nlc-EC  Event  (EOM,  )  >  — > 

Valld_Data_He8aage (data  msg) , 

T  — >  “ 

£alse  } 


type:  Event_Ll8t  -»  BOOL 

Annotations: 

•  The  correctness  of  an  ACK  at  the  INS  is  expressed  as  a  function  of  event  his- 

•  tory  only,  since  there  are  no  timing  constraints  (line  0). 

•  Only  the  last  two  elements  in  the  history  are  considered  (line  1).  (Note  that  the 
function  Last_n  returns  the  entire  history  if  the  history  has  less  than  two 
elements.) 

•  The  last  two  events  must  have  been  EC  events  (lines  2-3),  and  the  last  one 

^  must  have  been  an  EOM  that  terminates  the  message  (line  2).  The  identifier 

“data_msg"  Is  bound  to  the  event  Information  present  In  the  second  to  the  last 
event  (line  2). 

•  Note  that  since  the  time  stamps  are  of  no  concern,  no  Identifiers  are  provided 
for  those  components  in  the  pattern.  Pattern  matching  allows  for  comparing 
event  sequences  while  ignoring  time  stamps.  This  scheme  is  used  throughout 

•  the  specification. 

•  The  event  information  in  the  second  to  the  last  event  must  be  a  valid  data  mes¬ 
sage  (line  4).  Also  notice  that  the  presence  of  an  EOM^q  implies  that  the 
preceding  event  must  have  been  a  Data_Message  from  the  EC. 

•  If  the  last  two  events  did  not  match  the  pattern,  an  ACK  is  not  correct,  i.e.,  false 

•  is  returned  (lines  5-6).  This  includes  the  case  where  the  history  contains  fewer 

than  two  elements. 

2.4.2.2.  Protocol_Obeyed_atJNS 

The  INS  obeys  the  protocol  if  all  events  Initiated  at  the  INS  are  correct  in  the  context  of 
^  history  (the  tuple  of  previously  occurring  events). 


^This  Ada-like 
model. 


oommment  is  a  refaranoe  to  a 


paragraph  in  |14].  Referanoes  of  tNs  form  are  used  throughout  the  formal 
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0.  Protocol_Oboyed_at_INS  (history)  (ev«nt8_st__ins)  = 

1.  (event8_at_in8  ^  <>)  3 

2.  (let  fir8t_event  =  M  event8_at_ins  ^ 

3 .  (is-IWS  Event (£ir8t_event)  u 

4 .  Event_la_Correct_at_INS  (Filter_Event_I.i8t_at_INS  (history) ) 

(£ir8t_event) ) 

5.  A 

6 .  Protocol_Obeyed_at_INS (history  ^  <£irst_event>) 

(tl  event8__at_in8) ) 

type:  Eveiit_Li8t  -♦  (Eyent_Li8t  —*  BOOL) 

Annotations: 

•  This  function  uses  two  event  lists:  one  is  a  list  of  events  as  seen  at  the  INS;  the 
other  is  a  list  of  events  occurring  prior  to  the  first  list  as  seen  at  the  INS  (line  0). 

When  the  function  is  first  called,  the  history  is  empty,  <>,  and  the 
"events_atjns"  is  the  complete  list  of  events  as  seen  at  the  INS. 

•  The  function  is  defined  using  an  implication  starting  on  line  1 .  Recall  that  if  the 
antecedent  of  the  implication  is  false,  then  the  entire  implication  is  true.  In  fact 
the  implication  can  be  false  only  if  the  antecedent  is  true  and  the  consequent  is 
false.  The  antecedent  states  that  the  event  list  at  the  INS  is  not  empty.  This 
means  that  if  the  event  list  is  empty,  the  protocol  is  obeyed  by  the  INS.  The 
consequent  is  the  rest  of  the  function. 

•  Given  that  the  event  list  is  not  empty  (line  1),  the  first  event  is  the  head  of  the 
list  and  the  identifier  "firstjevent"  is  introduced  as  a  name  for  the  first  element 
(line  2). 

•  Since  at  the  INS  only  the  correctness  of  INS  events  Is  of  interest,  another  impli¬ 
cation  is  used  to  express  the  following:  if  ttie  first  event  is  an  INS  event  (line  3), 
it  must  be  correct  in  the  context  of  the  history  when  ignorable  EC  events  have 
been  removed  (line  4).  (See  Section  2.4.3.1  for  further  details  on  the  removal 
of  ignorable  events.) 

•  In  addition  to  the  first  event  being  correct  if  It  is  an  INS  event,  the  remaining  list 
of  events  must  be  correct  (line  6).  This  Is  expressed  by  calling  the  function 
recursively  with  an  extended  history  (adding  the  Tirst_event"  to  the  history 
tuple)  and  the  remaining  events  at  the  INS  (tl  events_atjns).  The  recursion 
leads  to  the  "events_atjns"  parameter  eventually  becoming  the  empty  tuple, 
which  will  terminate  the  recursion  by  the  condition  of  line  1 . 

2.4.2.3.  lnitlatlng_EF_Not_Too_Soon_at_EC 

There  are  several  EC  events  that  we  call  initiating  events.  Specifically  these  are  EF  events 
issued  by  the  EC  that  initiate  an  interaction  with  the  INS.  The  IDS  states  that  no  more  than 
two  of  these  Initiating  EF  events  may  occur  within  one  second.  These  initiating  events  are 
SOMgQ,  SOTM^q  and  A 1 1  N2gQ. 
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0.  lnitiating_EF_Not_Too_Soon_at_EC(f_history) (current_tiine)  = 

1.  (V  1, j  e  Ind  £_hiatory) 

2 .  ( (is -EC  Event (£_hiatory [i] )  a  is -EC  Event (£_history [ j ] ) 

3.  A  i  <  j 

4.  A  current_tijne  -  8-Tiine_StaiBp  (£_history  [i] )  S 

Min_Initiating_Pair_Separation_Tixne  )  z> 

5.  (let  gJc-EC  Event(event  in£o  i.  )  =  f_history[i] 

6.  let  mk-EC  Event (event  inf o_i ,  )  =  f_history[j]  iji 

7.  —1  {event_in£o_i,event_info_j)  c 

~  { SOM, SOTM, ATTN2 } ) ) 


type:  Event_List  -»  (TiiDe_Stanp  -♦  BOOL) 

Annotations: 

•  The  aforementioned  EF  initiation  rate  is  one  criterion  for  the  correctness  of 
these  initiating  EFs.  This  function  is  a  predicate  that  returns  true  if  the  condition 
is  satisfied  and  false  otherwise.  It  is  called  with  an  event  history  and  the  time 
associated  with  the  initiating  event  under  scrutiny  (line  0). 

•  The  condition  can  be  restated  in  terms  of  events  in  an  event  list  as  follows; 
given  any  two  events,  e1  and  e2,  such  that  e1  occurred  before  e2  and  e1  oc¬ 
curred  within  one  second  of  the  event  under  scrutiny,  then  they  should  not  both 
be  initiating  events. 

•  Line  1  expresses  this  in  Meta-IV  using  universal  quantification  over  the  indices 
of  the  event  history.  It  states  that  for  all  i  and  j  that  are  elements  of  the  index 
set  of  the  f_history,  some  condition  must  be  satisfied. 

•  The  condition  is  an  implication  that  begins  on  line  2.  Recall  that  if  the  antece¬ 
dent  of  the  implication  is  false,  then  the  entire  implication  is  true.  In  fact  the 
implication  can  be  false  only  if  the  antecedent  is  true  and  the  consequent  is 
false. 

•  The  antecedent  states  that  the  i’th  and  j’th  events  should  be  EC  events  (line  2), 
that  the  i’th  event  occurs  before  the  j’th  event  (line  3),  and  that  the  i’th  event  is 
within  a  specified  amount  of  time  (one  second  in  this  case)  from  the 
currenMime  (line  4).  This  amount  of  time  is  specified  by  the  constant  function 
Min_lnitiating_Pair_Separation_Time. 

•  The  consequent  states  that  the  set  comprised  of  the  i’th  and  j’th  event  should 
not  be  a  subset  of  the  set  of  initiating  EFs  (lines  5-7). 


2.4.3.  Basic  Techniques  Appiied  in  the  Model 

• 

2.4.3.1.  Filtering  of  Event  Lists 

A  general  property  of  the  protocol  is  that  EFs  that  are  received  out  of  sequence  at  the  INS 
(for  example,  due  to  a  transmission  error)  are  to  be  ignored  by  the  INS.  Out  of  sequence 
EFs  received  at  the  EC  may  either  be  ignored  or  responded  to  by  an  ATTN1.  To  reflect  the 
#  effect  of  ignoring  EFs  that  are  out  of  sequence  and  at  the  same  time  to  simplify  the  functions 
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in  the  model,  we  decided  to  explicitly  remove  ignorable  EFs  from  the  history  before  express¬ 
ing  the  correctness  of  the  following  event.  We  refer  to  this  process  as  "filtering.”  The  filtering 
functions  for  the  INS  and  the  EC  are  defined  in  Sections  5.3  and  6.3,  respectively. 

2.4.3.2.  Completeness  of  Event  Lists 

The  conditions  defined  by  the  correctness  ftinctions  of  the  model  basically  express  whether 
an  event  is  allowed  to  occur  in  a  given  context,  and  not  whether  it  is  required  to  happen. 
This  approach  takes  care  of  certain  forms  of  non-determinism,  i.e.,  contexts  where  one  of 
several  next  events  is  possible,  for  example,  in  the  case  that  the  EC  receives  an  EF  that  is 
out  of  sequence  and  may  respond  in  either  of  two  ways.  The  approach,  however,  means 
that  even  if  all  events  in  the  two  sequences  are  correct,  additional  events  may  be  required 
by  the  protocol.  This  is  not  captured  by  the  correctness  functions.  An  example  is  the  re¬ 
quired  sending  of  periodic  messages.  The  concept  of  such  "required  events"  is  expressed  in 
the  model  by  a  completeness  aiterion  that  defines  for  the  two  correct  event  lists  (at  the  INS 
and  at  the  EC)  whether  more  events  are  required  to  happen.  It  is  formalized  by  the  function 
ls_Complete,  which  is  defined  in  Section  4.2. 

2.4.3.3.  Use  of  Constant  Functions 

In  [14]  several  specific  numbers  are  used  to  define  time  intervals  for  required  response 
times,  periodicity,  etc.  To  symbolically  represent  the  numbers,  we  have  defined  a  set  of 
parameterless,  constant  functions.  The  names  of  these  functions  have  been  chosen  to  best 
reflect  the  role  of  the  number,  for  example,  the  function  "Attitude_Period"  is  defined  as  part 
of  describing  the  periodicity  of  attitude  messages  (its  value  is  6144,  measured  in  0.01  mil¬ 
lisecond  units).  The  constant  functions  are  defined  in  Section  7.2. 

2.4.4.  Structure  of  the  Formal  Model 

The  formal  specification  of  the  INS  communication  protocol  is  presented  in  the  remaining 
chapters.  Chapter  3  contains  the  type  equations.  Chapter  4  defines  functions  that  formalize 
the  protocol  at  the  systems  level  by  considering  both  the  INS  and  the  EC.  Chapters  5  and  6 
define  functions  that  are  specific  to  the  INS  and  the  EC.  respectively.  Chapter  7  contains 
general  functions,  some  that  express  important  constants  defined  by  the  protocol,  some  that 
provide  elementary  operations  on  one  of  the  types  defined  in  Chapter  3,  and  finally  some 
that  are  auxiliary  functions  used  by  several  functions  in  Chapters  4  to  6.  An  index  including 
all  functions  is  also  provided. 

The  type  equations  are  supplemented  with  annotations,  and  each  function  is  accompanied 
by  a  rationale  section.  Also,  when  appropriate,  functions  are  augmented  with  references  of 
the  form  -  6.3.2. 1.c.  These  are  references  to  sections  In  [14].  A  number  of  conventions 
that  are  not  dictated  by  VOM  have  been  used  to  Increase  the  readability  of  the  model.  They 
are; 


•  Type  names  in  our  model  always  begin  with  a  capital  letter. 

•  Function  names  always  begin  with  a  capital  letter. 
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•  Formal  parameters  and  objects  are  always  in  lowercase  letters. 

•  All  functions  specific  to  the  INS  have  a  name  ending  in  "_atJNS”.  Similarly, 
names  of  EC-specific  functions  end  In  "_at_EC". 

•  A  history  that  has  been  filtered  is  always  referred  to  as  "f.history*. 

It  may  be  helpful  to  read  the  functions  using  the  following  strategy: 

•  Read  the  rationale  for  a  function  before  trying  to  understand  the  function  itself. 
Functions  tend  to  be  decomposable  into  logical  segments.  The  rationale  mir¬ 
rors  this  decomposition. 

•  Read  the  top  level  functions  in  detail  (Chapter  4).  Then  read  the  first  three 
sections  of  INS  functions  and  EC  functions  (Chapters  5  and  6,  respectively). 
Become  familiar  with  the  function  hierarchy.  Read  selected  portions  in  detail. 

•  Keep  in  mind  that  the  specification  is  basically  three  predicates  (the  top  level 
functions)  .that  are  being  applied  to  two  sequences  of  events.  The  idea  is  that 
an  arbitrarily  long  communication  session  between  the  EC  and  the  INS  is  being 
examined  to  determine  whether  it  adheres  to  the  protocol.  This  is  expressed  by 
looking  at  each  event  (one  by  one)  in  the  context  of  all  previous  events  (the 
event  history)  and  examining  the  communication  event  sequence  as  viewed 
from  the  INS  and  as  viewed  from  the  EC.  Note  that  all  events  must  obey  the 
protocol.  Thus,  as  soon  as  one  event  fails  to  satisfy  the  conditions,  the  predi¬ 
cate  returns  false  and  no  further  examination  is  necessary.  This  generates  the 
following  assumptions  that  are  used  throughout  the  specification.  If  the  event 
sequence  represents  the  INS  perspective,  then  all  events  generated  by  the  INS 
that  are  in  the  event  history  satisfy  the  protocol.  If  the  event  sequence 
represents  the  EC  perspective,  then  all  events  generated  by  the  EC  that  are  in 
the  event  history  satisfy  the  protocol. 
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3.  Formal  Model  Type  Equations 

Sv*nt'_I<l«t  ■  Cv«nt* 

Cv*nt  B  INS_Ev*nfc  |  EC_Kv«nfc 

ZMS_Ev*nt  ZNS_Ev*nt_Znf  o  TiM>_8t«aip 

BC_Ev*n't  EC_Evant_Zn£o  TlawjBtan^ 

ZNS_Bv*nt._Zn£o  >  OomM_Evnt  |  ZMS_Mon_Coaans_Bv*nt 
EC_Ev«nt_Zn£o  —  Coinm«_Ev«nt  |  EC_BonjCoiaM_Ev*nt 

Coams_Ev«nt  b  Er_Ev*nt  | 


Data  B  Data  Elanant* 


Data  Elamant  b  TOKEN 


ZNS_Mon_Coiima_Evant  ■  8ZgnaZ_to_ZNS_0parator 
Slgnal_to_ZNS_Oparator  : :  QOOT 

EC_Mon_Coa«na_Ev«nt  b  81gnal_£xom_EC_0parator  |  8ignal_to_BC_Oparator 

81gnal_£xom_BC_0pazator  b  Enabla  Comma  |  Dlaabla  Coiwna  |  Sand  Taat 

Salaet  Xttltuda  |  Salact  Navigation  t 
Salaot  Nona  |  Salact  Both 

Slgnal_to_EC_ppazator  : :  QOOT 

Tl8ia_Stafl[^  B  HO 
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Annotations: 

•  Communication  between  the  two  computers  is  being  modeled  as  a  time- 
ordered  sequence  of  communications-related  events.  Thus  the  highest  level 
and  most  pervasive  object  type  in  the  specification  is  an  Event_List.  An 
Event.List  is  defined  as  a  tuple  of  Events. 

•  Each  Event  is  associated  with  one  of  ttie  two  computers,  the  INS  or  the  EC. 
Consequently  an  event  is  either  an  INS_Event  or  an  EC_Event. 

•  In  addition  to  being  able  to  model  sequential  ordering  in  time,  there  are  cir¬ 
cumstances  that  necessitate  modeling  time,  i.e.,  the  time  at  which  an  Event  oc¬ 
curred.  Thus  Events  (both  INS_Events  and  EC_Events)  are  modeled  as  two- 
component  trees.  The  first  component  captures  information  that  allows  further 
characterization  the  of  event  itself:  INS_EventJnfo  and  EC_EventJnfo.  The 
second  component,  Time_Stamp,  represents  the  time  at  which  the  event  oc¬ 
curred. 

•  Both  INS_Events  and  EC_Events  may  be  communications  events  or  non¬ 
communications  events.  Comms_Events  model  those  events  that  are  issued 
by  one  computer  and  may  directly  affect  the  other  computer.  These  are  either 
EF_Events  or  Data_Messages.  The  valid  EFs  are  enumerated.  An  extra 
EF_Event  event  is  included  to  capture  incorrect  EFs. 

Non-communications  events  (INS_Non_Comms_Event  and  EC_Non_Comms_ 
Event  for  the  INS  and  EC,  respectively)  represent  interaction  with  a  console  op¬ 
erator  or  some  other  external  influences  on  one  computer  that  are  not  from  the 
other  computer. 

•  Data_Messages  are  further  subdivided  into  periodic  and  non-periodic  mes¬ 
sages.  which  are  enumerated. 

Each  message  type  is  defined  as  a  tree.  Attitude,  navigation,  test,  and  time 
and  status  messages  are  single  component  trees,  the  component  being  the 
data  communicated  in  each  message,  respectively.  Data  are  later  defined  as  a 
tuple  of  Data_Elements,  which  are  TOKENS.  Recall  that  the  representation  of 
TOKENS  is  undefined.  Therefore  the  exact  nature  of  the  data  being  transmitted 
is  not  being  specified. 

The  fifth  message  type  is  the  select  data  message.  It  is  modeled  as  a  two 
component  tree.  The  first  component.  Data,  is  exactly  like  the  previous  mes¬ 
sages.  The  second  component,  Selected_Msg_Type,  conveys  information  con¬ 
cerning  the  content  of  the  Data.  Note  that  its  representation  is  not  specified, 
but  the  information  content  of  the  message  is.  The  Selected_Msg_Type  Is  fur¬ 
ther  defined  as  an  enumeration  of  the  four  commands  that  the  EC  can  issue  to 
the  INS  through  a  select  data  message;  namely,  to  commence  sending  periodic 
attitude  messages,  to  commence  serKfing  periodic  navigation  messages,  to 
commence  serving  both  periodic  messages,  or  to  stop  sending  periodic  mes¬ 
sages. 

•  The  next  several  type  equations  dead  with  INS  and  EC  non-communications 
events,  specifically  Interactions  with  each  computer’s  console  operator.  The 
INS_Non_Comms_Events  are  simply  signals  to  the  INS  operator— no  signals 
from  the  INS  operator  are  being  modeled.  They  are  not  specified  in  any  further 
detail,  since  they  are  by-products  of  communications  but  have  no  direct  impact 
upon  communications.  The  EC_Non_Comms_Events  are  either  signals  from  or 
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to  the  EC  operator.  Signal_from_EC_Operator  is  further  defined  as  an 
enumeration  of  the  commands  that  may  be  issued  by  the  EC  operator  and  im¬ 
pact  communications  between  the  two  computers. 

•  The  final  type  equation  simply  states  that  Times_Stamps  are  being  modeled  as 
natural  numbers.  Time  is  expressed  in  multiples  of  .01  milliseconds,  which  is 
the  accuracy  to  which  [14]  specifies  time. 
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4.  Formal  Model  Top  Level  Functions 

4.1.  Time  Stamps  Are  Non-Decreasing  in  Event  Sequences 

Tiine_Staxqp8_Non_I>ttcrttasing  (•▼•nt__ll8t)  « 

(V  1,  j  E  Ind  •V8nt_ll8t) 

({i  <  j)  3 

(8-TijDe_Staiap  (ev8nt_ll8t  [ID  S  £-Iljne_Stainp  (evant_list  [  j  ] ) ) ) 
type:  Event_Ll8t  -»  BOOL 

Rationale: 

•  Since  the  ordering  of  the  elements  in  a  tuple  of  events  captures  the  order  in 
which  these  events  occur,  the  time  stamps  of  the  events  must  be  non- 
decreasing  in  the  sequence.  The  reason  for  not  requiring  strictly  increasing  time 
stamps  is  that  the  model  allows  consecutive  events  to  happen  "at  the  same 
time"  (within  the  accuracy  of  the  time  measurement  units). 


4.2.  Determine  If  the  Protocol  Is  Obeyed 

Protocol_Ob8yed  (ay«nt8^8t_ln8 .  «yant8_8t_8c)  ■ 

Protocol_Ob8yed__8t^INS  (<>)  (  8V8nt8_8t__in8  ) 

A 

Protocol_Obey«d_8t_EC  (<>) (  •v«nt8_«t_8C  ) 

type:  Byent_Ll8t  ■y8nt^Ll8t  BOOL 

Rationale: 

•  We  model  communications  between  the  INS  and  EC  as  a  sequence  of  events. 
This  sequence  is  viewed  from  two  perspectives:  1 )  at  the  INS  communications 
ports,  and  2)  at  the  EC  communications  ports. 

•  Under  "normal"  situations  the  two  views  should  yield  identical  sequences 
(excepting  non-communications  events).  However,  if  transmission  errors  occur, 
then  the  differing  perspectives  may  yield  different  sequences. 
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4.3.  Determine  If  the  Event  Sequences  Are  Complete 

Is_Coii^lettt(ttVttnt8^at_ln8,  •▼•nts_at_«c)  ■ 

-I  (  3  event  6  (z  i  is -Event (x)  a  -■  ie-Siqn«l  from  EC  Operator (x)  )  ) 
(  Pzotocol_Obeyed(  event 8__et_inB  ^  <event>, 

event8  at  ec  <event>  )  ) 


type:  Bvent_Ll8t  Event_X<l8t  ->  BOOL 

pre:  Pzotocol_Obeyed  (event8_at_ln8 ,  event8_at_ec) 

Rationale: 

•  The  ProtocoLObeyed  function  determines  if  all  events  in  the  event  history  are 
correct  in  the  context  of  each  events  history.  Ail  events  that  have  transpired 
may  indeed  be  correct,  but  the  communications  protocol  may  dictate  that  a  fu¬ 
ture  event  must  occur. 

•  The  idea  captured  by  the  above  predicate  is  that,  if  an  event  could  happen,  it 
should  happen  (e.g.,  if  ACK||^3  can  occur  but  doesn't,  then  we  define  the  event 
sequence  as  incomplete).  Excepting  signals  from  the  EC  operator,  it  is  incor¬ 
rect  for  no  event  to  occur  when  there  is  an  event  that  can  occur  and  obey  the 
protocol.  The  only  type  of  event  that  can  occur  at  any  time  is  a  signal  from  the 
EC  operator. 

•  This  function  is  only  applied  to  the  event  history  if  the  history  obeys  the 
protocol,  and  thus  ProtocoLObeyed  is  a  precondition  to  this  function. 
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5.  Formal  Model  INS  Functions 

5.1.  Determine  If  Protocol  Is  Obeyed  at  the  INS 

Protocol_Obeyed_at_INS  (history)  (event8_at_ins)  « 

(event8_at_ln8  ^  O)  3 

(lat  flr8t_avant  >■  M  avent8_at_ln8  In 
(is-INS  Kvant  (£irst__avent)  z> 

Kvant_l8_Correct_at_IHS  <Filtar_Bvent_Li8t_at_IMS (history) ) 

(£irst_avant) ) 

A 

Protocol_Obayad_at_ZNS (history  *■  <£ir8t_avant>) (tl  event8_at_ins) ) 

type:  Bvent_Li8t  -»  (Bvant_List  -*  BOOL) 

Rationale: 

•  This  function  determines  if  the  protocol  is  obeyed  by  the  INS  as  seen  at  the 
INS;  i.e.,  ensures  that  the  INS  generates  correct  events.  Note  that  from  the 
INS  perspective,  its  own  events  are  correct  or  incorrect  and  EC  events  are  ex¬ 
pected  or  unexpected. 

•  This  function  examines  each  event  in  a  sequence  and  determines  if  it  is  correct 
in  the  context  of  a  filtered  history. 

•  Filter_Event_List_atJNS  removes  unexpected  EC  events  (caused  by  transmis¬ 
sion  errors),  thus  simplifying  the  event  stream  that  needs  to  be  examined  for 
completeness  and  correctness.  In  essence  this  process  removes  EC  events 
that  the  INS  may  ignore  (see  Sections  2.4.2.2  and  5.3). 

5.2.  Look  at  Each  INS  Event  In  Context  of  History 

Bvent_Is_Cotrect_at_lNS  (£_hi8tory)  (ln8_event)  = 

let  gJc-IWS  Bvant (eyent_ln£o, )  »  ln8_event  in 

(i8-Conin8  Bvent  (ev«nt_ln£o)  — > 

Coxom8_Eyent_l8  Correct_at  ZHS  (£_hl8tory)  (in8_event) , 

T  “  ~>~ 

Hon_CoiiBn8_Bvent_l8_Correct_at_INS  (f_history) ) 

type:  Byent__Ll8t  (INS_Eyent  ->  BOOL) 

Rationale: 

•  This  function  separates  the  treatment  of  communications  events  and  non¬ 
communications  events. 

•  Notice  that  the  name  of  the  history  parameter  is  f_hlstory.  This  signifies  that 
this  function  is  operating  on  a  previously  filtered  event  list. 
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5.2.1.  Look  at  Each  INS  Communications  Event  in  Context  of  History 

ConBna_Event_Is_Cortect_at_INS  (£_hiatory)  (lns_event)  = 

let  aJc-INS  Event (event_inf o, )  =  ins_event  ^ 

(  Is-EF  Event (event_in£o)  — > 

EF_Event_Ia_Cotrect_at_INS (£_hi8tory) (ins_event) , 

^-Data_Me3sage  (event_in£o)  — > 

Data_Event_Is_Correct_at_INS (£_history) (ins_event)  ) 

type:  Event_Liat  -»  (ZNS_Event  ^  BOOL) 

Rationale: 

•  This  function  separates  the  treatment  of  EF  events  and  data  events. 

•  Also,  notice  that  this  is  a  partial  function,  since  it  prescribes  no  result  for  non¬ 
communications  INS  Events. 
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5.2.1 .1.  Look  at  Each  INS  Communications  EF  Event  in  Context  of  History 

EP_Event_l8_Correct_at_IHS  (£_hiatory)  (ln8_event)  = 

let  mk-lNS  Event  (event  info. event  time)  »  ln8_event  in 
eaaea  event_ln£o: 

(  Age  — > 

ACK__l8_Correct_at_INS  (£_hl8tory) , 

ATTHl  ”  — > 

ATTNl_Ia_Correct_at_INS  (fjhiatory)  (event_tiine) , 

ATTM2  — >  ~ 

ATTN2_l8_Correct_at__lMS  {£_hi8tory) , 

ATTN4  — > 

ATTN4_1 8_Cor  rect_at_JCNS , 

EOM  — > 

E0M_l8_Correct_at_INS  (£_hi8tory)  (event_tiiDe) , 

HAK  “> 

NAK_Ia_Correct_at_INS  (£_hi8tory) , 

NRTR  — > 

lJRTR_l8_Correct_at_IKS  (£_hi8tory)  (event_tlme)  , 

RTR  — > 

RTR_Ia_Correct_at_INS  (£_hi8tory)  (event_tiine) , 

SOM  — > 

SOM_la_Correct_at_lKS  (£_hi8tory)  (event_tixDe) , 

SOTM  — > 

SOTM_Ia_Correet__at__lNS  (£_hi8tory)  (event__tiine) , 

Error  EF  — > 

false 

) 

type;  Event_l.ist  ->  (lKS_Event  ^  BOOL) 

Rationale: 

•  This  function  divides  EF  events  into  the  individual  EFs  and  invokes  functions  to 
express  the  conditions  for  the  individual  EFs. 

•  Also,  notice  that  this  function  is  partial,  since  it  does  not  prescribe  a  result  for 
non-communications  events  or  for  Data_Message  events. 
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5.2.1 .2.  Look  at  Each  INS  Communications  Data  Event  in  Context  of  History 

Data_Event_Is_Correct_at_INS(f_history)  (ins_event)  * 

let  mk-INS  Event (event_ln£o,  )  =  ln8_event  ^ 

(  is -Teat  Msg  (event__in£o)  — > 

Te8t_Msg_Is_Correct_at_INS (£_hlstory) (event_ln£o) , 

is-Time  end  Statua_Msq<avent_lnfo)  — > 

Time_and_Statua_Msg_l8jCorrect_at_INS  (£_hi8tory) , 

is-Attltude  Mao (event_in£o)  — > 

Attitude_Mag_l8_Correct_at_INS (£_hi8tory) (event_ixi£o) , 

is -Havigation  Mag (event_in£o)  — > 

Havigation_Mag_Ia_Correct_at_INS (£_hi8tory) (event_inf o) , 

T  — >  £al8e  ) 

type:  Event_Liat  -»  (INS_Event  -»  BOOL) 

Rationale: 

•  This  function  divides  the  data  events  into  ttie  four  data  messages  that  are  sent 
from  the  INS  to  the  EC  (see  [14],  p.  8-19,  Table  8-2). 

5.2.2.  Look  at  Each  INS  Non-Communications  Event  in  Context  of  History 

Non_ConBna_Event_Is_Correct_at_lNS  (£_J»istoty)  = 
Signal_to_Operator_l8_Correct__at__INS  (£__history) 
type:  Event_Li8t  ->  BOOL 

Rationale: 

•  The  only  INS  non-communications  event  is  a  signal  to  the  INS  operator. 


34 


CMU/SEI-88-TR-26 


I 


5.2.2.1.  Look  at  Each  INS  Signal  to  Operator  in  the  Context  of  History 


Signal_to_INS_0perator_l8_Correct._at_lMS  (f_hi8toty)  = 
Tljne_Out_Af  ter_ZC__Initiated_SOM_at_lHS  ( f_hi8tory ) 

V 

Tijne_Out_A£tet_EC_lnit  iated_SOTM^at_IHS  ( £_hi8tory ) 

V 

Error_A£ter_Second_SOM_at_lNS(£_hi8tory) 

V 

Error_A£ter_Second_SOTM_at_IHS ( £_hi8tory ) 

V 

Invalld_Me88age_0r_Te8t_Ma88age_JReealvad_at_INS (£_hl8tory} 

V 

ATTNl_Recelved_at_IMS  (£_hl8tozy) 


--  6.3.2.2.b 

—  6. 3. 2. 3. a 

—  6. 3. 2.1 

—  6.3.2.3.C 

—  6.3.2.2.C 

—  6.3. 6. 2. d 


type:  Event_Ll8t  ->  BOOL 

Rationale: 

•  Signals  to  the  INS  operator  indicate  error  situations  detected  by  the  INS.  Such 
errors  can  be  divided  into: 

•  An  INS  time  out  after  EC-initiated  communication  (after  SOM  or  SOTM) 

•  Failing  a  second  attempt  to  communicate  (after  SOMs  or  SOTMs) 

•  Receiving  invalid  messages  or  test  messages 

•  Receiving  an  ATTN1  from  the  EC  during  communication 


5.3.  Filter  Event  List  at  INS 

Filter_Eyent_Li8t_at_INS  ( event  8_at__ins)  = 

Reinove_Unexpected_EC_JBvents  (  <>  )  (  event8_at_in8  ) 
type:  Event_Ll8t  — »  Event_Ll8t 

Rationale: 

•  Out  of  sequence  EFs  are  ignored  ( [14],  6.3.6.2.e). 
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5.3.1.  Remove  Unexpected  EC  Events  from  Event  List 

ReinoTe_xnie^>ected_EC_Kv<ent8  (  history  )  (  •v«nt8_at_ln8  )  « 


(  event8_at_in8  *■  <>  — > 

(  let  flr8t_eTent  »  ^  events_at_lii8  ^ 

(  Is-KC  Kvent (£ir8t_eTent)  a 
is-Comma  Event (  8-EC_Event_Info(£ir8t_event) )  — > 

(  Cooins_Event_l8_Correct_at_EC (  history  ) (  fir8t_event  )  — > 
Rei80ve_Une]q>ected_EC_Event8  (history  ^  <fir8t_event>} 

(tl  event s_at_ins) 


T 

Iteinove__One3qpected_EC__Event8  (history  ) 

(tl  event8_at_ins)  ) , 

T  — > 

Reiiiove_Une]qpected_EC_Events (history  <£irst_event>) 

(tl  event 8_at_in8) ) , 


— > 


T 


— >  history  ) 


type:  Event_Li8t  -♦  (Event_Li8t  -»  Event_Liat) 

Rationale: 

•  Out  of  sequence  EFs  are  defined  as  those  that  do  not  satisfy  "EC  correctness." 

5.4.  Determine  Correctness  of  Individual  INS  EF  Events 

5.4.1.  ACK 

ACK_Is_Correct_jBt_INS  (£_history)  * 

cases  La8t_n(2,£_history) ; 

(  <  nk-EC  Event  (data  sisg,  ),  — 6.3.2.2.C 

nk-EC  Event (EOM,  )  >  — > 

Valid_Data_Me88age  (data_iiis9) , 

T  — > 

false  ) 


type:  Event_List  ->  BOOL 

Rationale: 

•  For  the  INS  to  Issue  an  ACK,  it  must  have  received  a  Data_Msg  followed  by  an 
EOM  and  determined  that  the  message  Is  valid. 

•  Notice  that  there  are  no  timing  requirements  between  receiving  an  EOM^q  and 
issuing  the  ACK||^3. 
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•  Also  notice  that  the  presence  of  an  EOM^q  implies  that  the  preceding  event 
must  have  been  a  Data_Message  from  the  EC. 


5.4.2.  ATTN1 

ATTMl_l8_Cotrect_*t_INS  (f_hi8tory)  (attnljbine)  = 

0  f_hlstoxy  *  O 

A 

la-IHS  Kvent (Last (£_hlatoxy) ) 

A 

(  let  nlc-IHS  Event (laat  event. laat  event  tine)  «  lAst (£_hlstory)  in 
la8t_event  €  (  SOM,  SOTM,  Ettt,  ATTW2  ) 

A 

®  attnl_tiine  -  last_event_tiiiie  >  TiBie_Out_Period_at_IMS  )  —  6.2.1.  g-h 

type:  Byent_Ll8t  — »  (Tian_8tamp  -*  BOOL) 

Rationale: 

^  •  The  last  event  in  the  history  must  be  an  INS  event. 

•  Moreover,  the  last  event  must  be  one  the  following  events:  SOM,  SOTM,  EOM, 
or  ATTN2  ( [14],  6.3.2.1  .a,  6.3.2.1.C,  6.3.2.3.C). 

•  When  awaiting  a  response  from  the  EC,  an  ATTN1  may  only  be  issued  upon 
the  expiry  of  the  timeout  period. 


5.4.3.  ATTN2 

ATTM2_l8_Correct_at_INS  (£_hi8tory)  “ 

£_hi8tory  ^  <> 

casea  Last (£_hi8tory) : 

(  mk-EC  Event (ATTN2.  ) 

T 

type:  Eyent_Llat  -»  BOOL 

#  Rationale: 

•  EC  is  responsible  for  enabling  communications  ( [14],  6.2.1). 

•  EC  sends  an  ATTN2  to  start  enabling  communications  ( [14],  6.2.1. b). 

•  INS  sends  an  ATTN2  only  in  response  to  ECs  ATTN2  ( [14],  6.2.1  .c). 


— >  true,  —  6.2.1.b-c 
— >  £al8e  ) 
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5.4.4.  ATTN4 

ATTN4_IsjCorrect_at_IHS  «  • 

false  ”  6.2.2 

type:  -»  BOOL 

Rationale:  ^ 

•  ATTN4  is  only  sent  by  the  EC. 


5.4.5.  EOM 

EOM__la_Correct_at_lNS  (£_hiatory)  (eoin_tlae)  *= 

£_hi8tory  *  O 

A 

cases  Last (£_blatory} : 

<  nb-IMS  Event (mk-Test  Msg (  ) ,  )  — > 

true,  — 6.3.2.1.C 

nk-lHS  Event  (mk-Tlsie  and  Status  Msg(  ),  )  — > 
true, 

mk-INS  Event  (aJc-Attltude  Msg  (  ) ,  )  — > 

Perlodlc_AttitudeJDeadllne_ls_Satis£lad(£_hl8tory) (eomjtlme) , 

mk-INS  Event  (tak-Havigation  lteq(  ),  )  — > 

Perlodic_Nayigatlon^Deadline_ls_^Sati8£ied(f_hl8tozy}  (eoim__^tijne) , 

T  — >  false  / 

type;  Eyent_Li8t  -*  (Tlme_Stanp  BOOL) 

Rationale: 

•  An  EOM  can  only  follow  the  sending  of  a  data  message.  The  INS  only  sends 
the  four  data  messages  that  are  specified. 

•  If  the  message  is  an  attitude  or  navigation  message,  the  EOM  must  meet  the 
periodic  timing  requirement  (see  Section  2.3.4). 
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5.4.5.1.  Determine  If  the  Attitude  Message’s  Deadline  has  Been  Met 

Perio<ilc_Attltude_I>fiadlln«_l8_Smtisflttd(f_hlstory)  (eom_tiine)  « 

let  end_of_prev_interval  e  NO  ^  s.t . 

end_o£_prev_lnterval*Attltude_Perlod  <  eom__tline 

A 

(end_o£_prev_lnterval-l-l)  *Attitude  Period  ^  eom  time 
in  ~ 

Select_Data_Request_£or_Attit\jde_in__lnterval  (£_hi8tory) 

(end_o£_prev_interval-l ,  end_o£_prev_int erval ) 

V 

EOM_£or_Attitude__ln_lnterval  (£_hlatory) 

(end_o£_prev_intetval-l ,  end_o£_prev_interval) 

type:  Event_Liat  -»  (Time_StaiBp  -»  BOOL) 

Rationale: 

•  The  model  of  periodicity  is  one  that  assumes  no  phase  shift  from  the  beginning 
of  execution.  The  periodic  intervals  are  therefore  set  at  the  beginning  of  execu¬ 
tion. 

•  This  function  first  determines  the  interval  number  of  the  interval  containing  the 
EOM  in  question  and  then  determines  if  the  previous  interval  contains  either  a 
select  data  message  or  an  EOM. 

•  If  the  previous  interval  does  not  contain  one  of  the  two  aforementioned  events, 
then  the  EOM  in  question  is  in  the  wrong  interval  (i.e.,  should  have  been  in  a 
previous  interval). 

•  Note  that  Attitude  Period  is  a  constant  function  defined  in  Section  7.1 .4. 
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5.4.5.2.  Determine  If  Select  Data  Message  for  the  Attitude  Message 
Is  in  Designated  Interval 

Select_Data_Itequest_£or_Attltude_in_Xnterval (£_hl8tory} (start,  end)  = 
£_history  ^  O 

A 

cases  Last (£_hlstory) : 

(  mlc-EC  Kvent (mk-Seleet  Data  Maa(  /Attitude) , sd  mag  time  ))  — > 
sd_ai8g_tiina  >  start*Attitude_Perlod 

A 

8d_i&8g_tijne  ^  end*Attltude_Perlod, 

mk-EC  E'yent  (mk-Seleet  Data  Maq(  ,  Both) ,  sd  mag  time  ))  — > 

sd_in8g_time  >  8tart*Attitude_Period 

A 

sd_asg_tiiBe  ^  end*Attitude_Period, 


T  — > 

Select_Data_Reque8t_£or_Attitude_in_Interval 

(  Front (£_history)  )  (start,  end)  ) 


type;  Event_Li8t  -»  (MO  MO  -»  BOOL  ) 

Rationale: 

•  This  function  recursively  searches  for  a  select  data  message  that  selects  at¬ 
titude  messages  (by  explicitly  requesting  attitude  messages  or  by  selecting  both 
periodic  messages).  It  then  determines  if  the  time  associated  with  the  message 
is  in  the  designated  interval. 
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5.4.5.3.  Determine  If  EOM  Following  an  Attitude  Message  Is  in  the  Designated 
Interval 

EOM_£or_Attltude_in_Zntexval(f_hl8tory) (start,  end)  « 
cases  I,ast_n  (2 ,  £_lilstoxy) : 


(  <bi1c-IHS  a^ent  (nk-Attltude  Msg  (  ) ,  > , 

aJc-IMS  Event  (EOM.  eom  tia>e)>  — > 

start*Attltuda_Perlod  <  eaBi_tlne 

A 

end*Attltude_Perlod  2  eom_tlsia, 

<>  — > 

false, 

T  — > 

EOM_£or_Attltuda_ln_Interval (  Front (£_history)  )  (start,  end)  ) 

type:  Event_Ll8t  -¥  (MO  HO  -»  BOOL  ) 

Rationale: 

•  This  function  recursively  searches  for  an  attitude  data  message  followed  by  an 
EOM  and  then  determines  if  the  time  associated  with  the  EOM  is  in  the  desig¬ 
nated  interval. 


5.4.5.4.  Determine  If  the  Navigation  Message’s  Deadline  Has  Been  Bet 


Perlodlc_Navlgatlon^Deadllna^ls^Satls£lad(£_Jil8tory)  (eon^tiine)  ^ 

let  «nd_o£_prev_interyal  €  HO  s.t. 

end_o£__prev_interval*Mavigation_Period  <  eom_tiine 

(end_o£_prev_interval+l)  *Havigation_Period  S  eoin_tia>e 
in 

Select_Data_Raque8t_£or_Havigatlon_ln_Interval ( £_hist ory ) 

(and_o£_prey_interval-l ,  end_o£_prev_interval) 

V 

EW4_£or_Hayigation_in_Intarval(£_hi8tory) 

#  (end_o£_prey_interval-l,  0nd_o£_prev_interyal) 


type:  Event_Ll8t  -»  (Tlsie_Staap  -»  BOOL) 

Rationale: 

•  See  rationale  for  attitude  message  meeting  its  deadline  (5.4.5.1). 
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5.4.5.5.  Determine  If  Select  Data  Message  for  the  Navigation  Message  Is  in 
Designated  Interval 

Select_Oata_Reqa«8t_£or_Mavigation_in_In^«zval(f__hi8tory)  <8tart,  end)  = 
£_hi8tory  *  O 

A 

cases  Last (£_hi8tozy) : 

(  mk-INS  Event (sdc-Select  Data  MsqC  .Navigation) ,ad  nsq  tine  ))  — > 
8d_nsg_tiiBe  >  start*Navigation_Period 

A 

sd  mag  tine  ^  ezul*Mavigation_Period, 

mk-INS  Kvent  (nk-Select  Data  Msg  (  ,  Both) ,  8d_nt8g_time  ) )  — > 

8d_iiisg_tijBe  >  8tart*Navigation_Period 

A 

8d_iiisg_tiae  ^  end*Mavigation_Period, 

T  — > 

Select_Data_Reque8t_£or_Navigation_in_Interval 

(  Front (£_history)  )  (start,  end)  ) 

type;  Event_List  ->  (NO  NO  -»  BOOL  ) 

Rationale: 

•  This  function  recursiveiy  searches  for  a  Seiect  Data  message  that  selects 
Navigation  messages  (by  explicitly  requesting  Navigation  messages  or  by  se¬ 
lecting  both  periodic  messages).  It  then  determines  if  the  time  associated  with 
the  message  is  in  the  designated  interval. 
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5.4.5.6.  Determine  If  EOM  Following  Navigation  Message  Is  in  Designated 
Interval 

EC»l_for__Mavigation_ln_Interval  (£_hi8tory)  (start,  end)  = 
f^hlstory  *  O 

A 

cases  Last_n(2, f_hlstosy) : 

(  <mlc-IWS  Event  (nlc-Naviaatlon  Msg  (  ) ,  ) , 
nk-IMS  Event  (E^,eom  tline)>  — > 

eoia_tiaie  >  8tart*Mavlgation_Perlod 

A 

eoim_tl]Be  <  end*Navigatlon_Perlod, 


T  — > 

E^_£or_Navigatlon_ln_Intexval (  Front  (£_hlstory)  )  (start,  end)  ) 
type:  Event_Llst  -»  (KO  SO  -»  BOOL  ) 

Rationale: 

•  This  function  recursively  searches  for  a  navigation  data  message  followed  by 
an  EOM  and  then  determines  if  the  time  associated  with  the  EOM  is  in  the 
designated  interval. 

5.4.6.  NAK 

NAK_l8jCorrect_at__lNS(£_hi8tory)  = 

cases  Last  n(2,£  history);  — 6.3.2.2.C 

(  <  nlc-EC  Event  (data^asg,  ) ,  nk-EC  Event  (E<»4,  )  >  — > 

-I  Valld_Data_Message (data_Bsg) , 

T  — > 

£alse  ) 


type:  Event_Ll8t  -»  BOOL) 

Rationale: 

•  For  the  INS  to  issue  a  NAK,  it  must  have  received  a  Data_Msg  followed  by  an 
EOM  and  determined  that  the  message  is  invalid. 

•  Notice  that  there  are  no  timing  requirements  between  receiving  an  EOM^q  and 
issuing  the  NAKj^g. 

•  Also  notice  that  the  presence  of  an  EOM^q  implies  that  the  preceding  event 
must  have  been  a  Data_Message  from  the  EC. 
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5.4.7.  NRTR 

NRTR_l8_Correct_«t__IHS  = 
false 


type:  -♦  BOOL 

Rationale: 

•  P.  4-9  of  [14]  states  that  NRTR  is  not  transmitted  by  the  INS. 

5.4.8.  RTR 

RTR_Ia_Correct._at__INS  (f_hi8tory)  (rtr_tijBe)  = 
f_history  ^  <> 

A 

cases  Last (f  history) :  — 6.3.2.2.a-b 

(  nk-EC  Event  (SOM,  8om_tisie)  — > 

xtr_tiiae  -  sometime  S  EC_Tinie_Out_Period, 

mk-EC  Event (SOTM,  aota_time)  — > 

rtr_tline  '  sotn  tiioe  ^  EC_Tiine  Out  Period, 


T 

false  ) 


— > 


type;  EventJLlst  -»  (Tline__Staiip  -»  BOOL) 

Rationale: 

•  SOMgQ  or  SOTM^c  niust  immediately  precede  an  RTR. 

•  Moreover,  the  RTR  must  be  issued  within  the  EC  allowed  time-out  period. 
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5.4.9.  SOM 

SMf_Is_Corr*ct_at_lHS  (£_hlstoxy)  (som_tijne)  = 

(  Perlodlc_Me8sages_Axe_Actlvated(£_hi8tory)  a 
S^_Z8jCorrect_inien_Parlodlc_M8g8^Are_Activated_at_INS  (£_hi8tory)  ) 

V  — 6.2.1. £ 

SWl_l8_Correct_Hhaa_Pariodie_M8gs_Are_Not_Activated_at_lNS  (£_history) 
type:  Event__Ll8t  — >  (Tiiiie_Staiip  ->  BOOL) 

Rationale: 

•  An  S0M||>^3  Is  correct  if  periodic  messages  from  the  iNS  to  the  EC  are  enabled, 
or 

•  An  S0M||^3  is  also  correct  after  the  enabling  sequence  at  the  beginning  of  the 
message  exchange  for  sending  a  time  and  status  message. 

5.4.9.1.  Determine  If  Periodic  Messages  Are  Activated 

P«rlodlc_Me88aga8_Ara_Act Ivatad  ( £_hl8tory )  - 
£_hi8tory  *  <> 

A 

if  i8-EC  Event (La8t (£_hi8tory) )  then 

let  iPk-EC  Event (la8t  event.)  =  La8t(£_hi8tory)  Ja 
(  la8t_eyent  «  ATTN2  — >  £al8e,  — 6.2.1.C 

la8t_eyent  ■  ATTN4  — >  £al8e/  — 6. 2.1. a 

laat_eyent  •*  ak-Select  Data  Mag(  .None  )  — p.8-10 

— >  false, 

last_eyent  «  nJc-Select  Data  Meat  .Attitude  ) 

— >  true, 

la8t_eyent  »  mIc-Select  Data  Msq(  .Navigation  ) 

— >  true, 

la8t_event  *  mk-Select  Data  KsqC  , Both  ) 

— >  true, 

T  — > 

Periodic_Mes8age8_Are_Aetivated(  Front (£_history)  ) 

else 

Perlodic_Me8sage8_Are_Activated(  Front (£_hi8tory)  ) 
type:  Bvent_List  -*  BOOL 

Rationale: 

•  Periodic  messages  are  activated  only  if  a  select  data  message  (for  attitude 
data,  navigation  data,  or  both)  exists  In  the  history  and  an  ATTN2  or  ATTN4  or 
select  data  for  no  data  does  not  ocoir  later. 
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5.4.9.2.  Given  that  Periodic  Messages  are  Activated.  Is  SOM  Correct? 

S0M_l8_Cotr«ct_llh«n_P«tiodic_llsga_Ar«_Activ«t«d_at_IHS (fjaistoty)  (8oia_tiine) 

caaea  Mua>ber_0£_Ottt8t.andlng  S^(a^Sent._at._IMS  (£__hl8t.ory)  : 

(0  — > 

caaea  Laat  nl2,t  hlatory) :  — 6. 3. 2. 2. a 

(  <  m)c-EC  Bvnt  {  ,  ) , 

wk-Itis  gvant(AClC,  )  >  — > 

true, 

<  aJc-IMS  Event  (  ,  ) , 

adc-lNS  Event  (event  in£o,  )  >  — > 

la-Slqnal  to  IHS  Operator (event  info) , 

<  nk-IHS  Event (  ,  ) , 

aJc-EC  Event  (ACK,  )  >  — > 

true, 

<  nk-EC  Event (  ,  ) , 

mk-EC  Event (event  in£o,  )  >  — > 

ia -Signal  to  EC  Operator (event_ln£o) , 

T  — > 

£alae  ) , 

1  — > 

caaea  I,a8t(£  hiatory) ; 

(  ^-INS  Event  (e£,  )  — > 

e£  =  ATTNl, 

nk-EC  Event  (e£,  e£_tiiae)  — > 

e£  >  ATTKl 

V 

e£  «  HAK 

V 

(  e£  s  WRTR  A 

aoai__tiiBe  -  e£_ti]Be  >  Sleep_Perlo<l  ) ) , 


T  — >  £alae  ) 
type:  Event_Li8t  — »  ( 

Rationale: 


(Tiine_Stasqp 


BOOI.) 


•  If  there  are  no  outstanding  SOMs  (i.e.  no  incomplete  message  transfer  se¬ 
quences  from  the  INS  to  the  EC),  then  the  SOM  must  follow  one  of  the  in¬ 
dicated  EF  events  or  a  signal  to  the  operator. 

•  If  there  is  one  outstanding  SOM,  then  the  SOM  in  question  must  follow  an 
ATTN1,NAK,oran  NRTR. 

•  If  It  follows  an  NRTR,  there  must  be  at  least  a  Sleep_Period  separation  In  time. 
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5.4.9.3.  Given  that  Communications  Have  Just  Been  Enabied,  Is  SOM  Correct? 


SOM_Ia_Correct_When_Periodic_Msgs_Are_Hot_Activated_at_INS (f_history)  = 

— 6.2.1. e  £  6. 3. 2.1.6 

casea  Nuinber_Of_Outatanding_SW4a_Sent_at_IMS  (f_hi8tory)  : 

(0  — > 

Enda_ln_Enabling_Sequenca (f_hlatory) ,  — 6 . 3 . 2 . 2 . a 

1  — > 

let  i  e  ind  £_hiatory  te  a.t. 

Huaiber_of_Outatanding_SOMa_Sent_at_IMS 
(  <  £_hiatory[jl  |lSj<i>)«0 

A 

(V  Ic  €  ind  £_hiatory) 

((  Jc  >  i)  =) 

(  caaea  £_hiatory[kl : 

(  nk-lMS  Event (SOM,  )  — >  £alae, 

T  — >  true  ) ) 

In 

Enda_in^Bnabllng_Sequence (  <  £_hlatory[j]  |  1  ^  j  <  i  >  ) 

A 

caaea  Laat (£_hlatory) : 

(  5k-INS_Event(e£,  )  — > 
e£  =  ATTNl, 

aJc-EC  Event  (e£ ,  e£_tiiBe)  — > 
e£'‘=  ATTWl  “ 

V 

e£  =  NAK 

V 

(  e£  s  WRTR  A 

aom_tijne  -  e£_tiine  >  Sleep_Period  } , 

T  — >  falae  ) 
type:  Event_Liat  -»  BOOL 

Rationale: 

•  If  the  SOM  is  the  beginning  of  a  message  transfer  of  the  time  and  status  mes¬ 
sage  and  this  is  the  time  and  status  message  that  is  due  immediately  after  com¬ 
munications  have  been  enabled,  then  ttie  SOM  must  be  preceded  immediately 
by  the  enabling  sequence. 

•  The  SOM  could  also  be  the  start  of  a  retry  for  this  message  transfer. 
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5.4.10.  SOTM 

SOTM_l8_Cori:«ct_at_INS  (fjbistoiry)  (sotmjtijne)  » 

cases  N'uinbar_of_Outstanding_SOTMs_Sent_at_INS  ( f_hi8tory)  :  — 6 . 3 . 2 . 2 .  a-c 

(0  — > 

cases  Xiast_n(3,  £_hlstory)  : 

(  <  afc-EC  Kvent  (nk-Test  MsgQ,  ), 
mk-gC  Bvent (EOM,  ) / 
nk-INS  Event (ACK.  )  >  — >  true, 

<  mk-EC  Bvent  (mk -Test  MsgQ,  ), 
nk-EC  Bvent (EOM,  ) , 
mk-lMS  Event (KAK,  )  >  — >  true, 

T  — >  false  ) 


1  — > 

cases  Last (£_hl8tory) : 

(  nk-IHS  Event (e£,  ) 
ef  =  ATTOl, 


— > 

— 6. 3.2.1. b  £  6.3. 6. 2. a 


nk-EC  Event (ef,e£  time  )  — > 

e£  =  ATTNl  —6. 3. 6.1 

V 

ef  «  HAK 

V 

(  ef  »  MRTR  A 

sotn  tine  -  e£_tlme  >  Sleep  Period  ) 

— 673. 2.1. b 


T  — >  false  ) 


type:  Event_Li8t  -»  (Tljne_Staii5>  BOOL) 

Rationale: 

•  If  there  are  no  outstanding  SOTMs  (l.e.,  no  incomplete  test  message  transfers 
from  the  INS  to  the  EC),  then  an  SOTM  must  follow  one  of  the  event  triples. 

•  If  there  is  one  outstanding  SOTM,  then  the  SOTM  in  question  must  follow  an 
ATTN1.  NAK,  or  an  NRTR. 

•  If  it  follows  an  NRTR,  there  must  be  at  least  a  Sleep_Period  separation  in  time. 


48 


CMU/SEI'88-TR-26 


5.5.  Determine  Correctness  of  individual  INS  Data  Message  Events 


5.5.1.  Test  Message 

Te8t_Mag_Is_Correct_at_IKS  (£_hi8tory)  (event_info)  = 

cases  Last_n(2, £_hlstory)  — €.3. 2.1. a  £  6.3.2.3.C 

(  <  mfc-INS  Event (SOTM,  ), 

nlc-EC  Event  (RTR,  )  >  — >  true, 

T  — >  false  ) 

A 

let  i  €  ind  £_hi8tory  s.t.  — 6.3.2.3.C 

cases  <  £_historytj]  |  i  ^  j  ^  1+2  >: 

(  <  nk-BC  Event  (nk-Test  Msg  (  ) ,  ) , 
nk-EC  Event (EOM,  ) , 

mk -INS  Event  (e£,  )  >  — >  e£  e  (ACK,  NAK), 

T  — >  false  ) 

A 

(  V  j  e  Ind  £_hl8tory  ) 

(  (  j  >  1+2  )  3 

(  cases  <  £_hlstory[nL]  |  j-2  S  m  S  j  >: 

(  <  nk-EC  Event (nk-Test  Msg (  ) ,  ) , 
nk-EC  Event  (EW,  ) , 

nk-INS_Event(e£,  )  >  — >  e£  0  (ACK,  NAK), 
T  — >  true  )  )  ) 


In 

event_lnfo  =  s-EC_avent_In£o (  £_hlstory[l]  ) 
type;  Event_Llst  -+  (INS_Event_In£o  -»  BOOL) 

Rationale: 

•  SOTM  and  RTR  must  immediately  precede  a  Test_Msg. 

•  Also,  the  test  message  data  must  be  the  same  data  received  in  the  initiating 
test  message  from  the  EC. 
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5.5.2.  Time  and  Status  Message 

Tiiiie_and_Status_Hag_l8_Corr«ct_at_lHS  (£_hi8tory)  = 

TSM_l8_Coxrect_A£ter_Enabllng__Sequence(f_hl8tory)  — 6.2.1.£  fi  p. 8-32 (a) 

V 

TSM_l8_Correct_A£ter_Seleet_Data_M8g (£_hi8tory)  — p . 8-32 (b) 

type:  Bvent_Ll8t  — »  BOOL 

Rationale: 

•  The  time  and  status  message  can  be  sent  on  two  occasions:  1 )  immediately 
after  the  enabling  sequence,  and  2)  immediately  after  the  INS  receives  a  select 
data  message  from  the  EC. 

•  Note  that  [14],  p.  8-32c,  specifies  an  additional  condition  for  sending  a  time  and 
status  message.  This  condition  is  not  being  modeled. 

5.5.2.I.  Determine  If  Time  and  Status  Message  Is  Correct  After  Enabling 
Sequence 

TSM_l8_Correct_A£ter_Enabllng_Seguence (f_history)  = 

caaea  Laat_n (2 , £_hiatory) ;  — 6 . 3 . 2 . 1 . a 

(  <  5*-INS_Event  (S^,  ) , 

mk-EC  Event (RTR,  )  >  — > 

SOM_I  a_Correct_When_Periodic_Mag8_Are_Not__Act  i  vated_at_lMS 
(Front (Front (£_hiatory) ) ) , 

T  — >  £alae  ) 

type:  Eyent_Li8t  -+  BOOL 

Rationale: 

•  The  message  must  be  preceded  by  an  SOM  and  an  RTR. 

•  In  addition,  the  enabling  sequence  must  precede  those  initial  EFs.  This  is  en¬ 
sured  by  stripping  off  the  SOM  and  the  RTR  and  applying  the  function  that  en¬ 
sures  that  an  SOM  is  correct  when  periodic  messages  are  not  activated.  The 
only  place  that  an  SOMjf^g  can  appear  when  periodic  messages  are  not  ac¬ 
tivated  is  immediately  after  an  enabling  sequence. 
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5.5.2.2.  Determine  if  Time  and  Status  Message  is  Correct  after  Seiect  Data 
Message 

TSM_la_Correet_A£ter_Select_Data_Msg (£_hi8tory)  « 


cases  Last_n  (2 ,  £__history)  : 
(  <  sJc-INS  Bvent(SOM, 
aJc-EC  Event  (RTR.  ) 
T 


—6. 3. 2.1. a 


>  — >  true, 

— >  £alse  ) 


A 

cases  Nuiaber_0£_Outstanding_S0Ms_j5ent_at_IMS  (£_history)  : 

(1  — > 

let  trunc_£_history  *  Front  (Front  (£_hlstosy) )  ^  — p.e-32(b) 

cases  X<ast__n(3,  trunc_£_hlstory}  : 

(  <  nlc-EC  Event  (  nk-Select  Data  Msg  (  ,  Attitude)  ) , 
aJc-EC  Event  (EOM,  )  , 
aik-INS  E^rent  (ACE,  )  >  — >  true, 

<  nk-EC  Event (  nk-Select  Data  Msg (  ,  Navigation)  } , 
nk-EC  Event  (E^,  )  , 

nk-INS  Event (AGE,  )  >  — >  true, 

<  nk-EC  Event (  nk-Select  Data  Msg (  ,  Both)  ) , 
nk-EC  Event (EOM,  ) , 

nk-INS  Event (ACE,  )  >  — >  true, 

T  — >  £al8e  > , 


2  — > 

TSM__IejCorreet_A£ter_Select_J>ata__M8g( 

Front  (Front  (Front  (£_hlstory)))  *  l,ast_n(2,  £_hi8tory)  ) 

T  — >  False  ) 

type:  Event_Llst  —*  BOOL 

Rationale: 

•  The  message  must  be  preceded  by  an  SOM  and  an  RTR. 

•  A  select  data  message  must  precede  the  SOM  that  initiated  the  message  trans¬ 
fer.  Moreover,  the  select  data  message  indeed  must  opt  for  data  to  be  sent. 


CMU/SEI-88-TR-26 


5.5.3.  Attitude  Message 

Attitude_ltog^l8_Corr«ct_«t_IHS  (f_hi8tory)  (•v8nt_lnfo)  ■ 

cases  Last_n(2, f_hlstory) : 

(  <  nk-lNS  KventCSOM,  }, 

nlc-BC  Event (RTR.  )  >  — >  Valid_Data_Me8sage (event_in£o) , 

T  — >  false  ) 

type:  Event_Llst  -»  (INS_lvent_Iafo  ->  BOOL) 

Rationale: 

•  Given  the  correctness  of  SOM  at  the  EC  (which  has  already  been  established, 
see  Section  2.4.4.),  the  event  sequences  above  are  the  only  ones  that  may  im¬ 
mediately  precede  an  Attitude_Msg.  or  any  non-test  message  for  that  matter. 

•  Correctness  of  the  appearance  of  a  periodic  message  is  actually  expressed 
when  EOM  is  checked.  At  that  point  periodicity  and  timeliness  are  checked. 

5.5.4.  Navigation  Message 

Naviostion_Ksa_Is_Corrset_at_INS (f^hlstoxy) (•▼•nt_lnfo)  b 

cases  Last_n(2, £_history) : 

(  <  ^-INS_E^nt  (SOH,  ) , 

mk-EC  Event (RTR,  )  >  — >  Valld_Data_M8g(event_ln£o) , 

T  — >  false  ) 

type:  Event_^Ll8t  -♦  (INS_Event_lnfo  -»  BOOL) 

Rationale: 

•  Given  the  correctness  of  SOM  at  the  EC  (which  has  already  been  established, 
see  Section  2.4.4),  the  event  sequences  above  are  the  only  ones  that  may  im¬ 
mediately  precede  a  Navigation_Msg,  or  any  non-test  message  for  that  matter. 

•  Correctness  of  the  appearance  of  a  periodic  message  is  actually  expressed 
when  EOM  is  checked.  At  that  point  periodicity  and  timeliness  are  checked. 
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5.6.  Determine  the  Correctness  of  Each  INS  Signal  to  Operator 


5.6.1.  Time-Out  After  EC  Initiated  SOM  at  INS 

TljaeiJ>ut_A£ter_KC_Initi«t«Kl_SOM_*t_lHS  (£_hi8toty)  = 

cases  Ziast_n(3,  £_hlstory} : 

«mlc-EC  Event  (SOM,  ) , 
mk-INS  Event (RTR,  ), 
nJc-INS^Bvent  (ATTMl,  )  >  — >  true, 

T  — >  false) 

type:  Eveht^Llst  -»  BOOL 

Rationale: 

•  The  INS  will  time  out  the  EC  (causing  an  ATTN1  to  be  sent)  and  alert  the  oper¬ 
ator  if  the  EC  does  not  send  its  message  within  10.24  ms  after  the  INS  is  ready 
( [14],  6.3.2.2.b).  The  time-out  period  is  not  used  by  this  function  but  is  used 
when  expressing  the  correctness  of  the  ATTN1  being  sent  before  the  signal  to 
the  operator. 

•  [14]  6.3.2.1.a  is  read  to  imply  that  ATTN1  is  issued  before  the  operator  is 
alerted. 


5.6.2.  Time-Out  After  EC  Initiated  SOTM  at  INS 

Tiine_Out__A£t«r_BC_Initiatad_SOTM_at__INS  (f_history)  = 

cases  Last_n(3,£_history) : 

«Bdc-EC  Event  (SOTOf,  ) , 
nk-INS  Event (RTR,  ), 

^-INS  Event  (ATTNl,  )> 

T  “ 


type:  Event__Ll8t  -♦  BOOL 

Rationale: 

•  The  INS  will  time  out  the  EC  (causing  an  ATTN1  to  be  sent)  and  alert  the  oper¬ 
ator  if  the  EC  does  not  send  its  test  message  within  10.24  ms  after  the  INS  is 
ready  ( [14],  6.3.2.2.b,  6.3.2.3.a).  The  actual  time-out  period  is  used  when  ex¬ 
pressing  the  correctness  of  the  ATTN1  being  sent  before  the  signal  to  the  oper¬ 
ator. 

•  [14]  6.3.2.1.a  is  read  to  Imply  that  ATTN1  is  issued  before  the  operator  is 
alerted. 


— >  true. 
— >  false) 
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5.6.3.  Error  After  Second  SOM  at  INS 

Error_A£tet_Second_SC»l_«t_IHS  (f_hi8tory)  « 
rime_Out_A£ter_Second_SOM_at_INS  (  f_hlstory ) 

V 

NRTR_Recaiv«d_A£ter_Second_S0K_at_INS(£_hi8toty) 

V 

NAK_Raceivad_A£ter__Second_S0M_at_IMS(f_hi8tory) 
type:  Bvent_Z.l8t  ->  BOOL 

Rationale; 


—  6.3.2.1.a(2) 

—  6.3.2.1.b(2) 

—  6.3.2.1.e 


•  Failing  a  second  attempt  to  communicate  after  a  SOM  is  due  to  any  of  the  fol¬ 
lowing: 

•  An  INS  time  out  occurs 

•  The  EC  is  not  ready  (NRTR) 

•  The  message  is  not  accepted  by  the  EC  (NAK) 


5.6.3.1.  Time<out  After  Second  SOM  at  INS 

Tiine_Out_X£ter_Second_SOM_at_INS  (£_hi8tory)  * 

NuinberjO£__Out8tanding_SOMa_Sent_at__lNS(£_hi8tory)  «  2 

A 

caa«8  Iia8t(£  hlatory) : 

(^-INSJE^t  (ATTWl,  )  ~>  true. 

T  — >  false) 

type:  Bvent_Ll8t  ->  BOOL 

Rationale: 

•  An  INS  time  out  of  the  EC  always  resuite  in  an  ATTN1  being  sent  to  the  EC 
( [14],  6.3.2.1  .a(2),  6.3.6.2.a,  6.3.2.1.C.).  This  covers  time  outs  directly  following 
the  second  SOM  as  well  as  ^ose  following  the  EOM. 

•  [14]  6.3.2.1.a  is  read  to  imply  that  ATTN1  is  issued  before  the  operator  is 
alerted. 
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5.6.3.2.  Received  an  NRTR  After  Second  SOM  at  INS 

MRTR_Received_A£ter_Second_SOM_at_INS  (£_history)  = 

Muiiiber_Of_Outatanding_SOMs_S«nt_«t_INS  (f_history)  =  2 

A 

cases  Z«st (£_hlstosy) : 

(nlc-BC  Event  <NRTR.  )  — >  true. 

T  — >  false) 

type:  Event_Llst  -»  BOOL 

Rationale: 

•  If,  by  the  second  attempt,  the  EC  is  not  ready  to  receive  a  message,  the  INS 
operator  is  alerted  ( [14],  6.3.2.1  .b(2)). 

5.6.3.3.  Received  a  NAK  After  Second  SOM  at  INS 

MAK_Recelyed__A£ter_Secoxxd_SOM_at_IMS  (£_hlstory)  = 

Nuniber_0£_Outatanding_SOMs_Sent_at_IMS<f_history)  =  2 

A 

eases  Last (£_hlstosy) : 

(mit-EC  Event  (NMC,  )  — >  true, 

T  — >  false) 

type;  Eyent_List  -*  BOOL 

Rationale: 

•  If,  by  the  second  attempt,  the  EC  does  not  acknowledge  the  receipt  of  a  mes¬ 
sage,  the  INS  operator  is  alerted  ( [14],  6.3.2.1.e). 

5.6.4.  Error  After  Second  SOTM  at  INS 

Error_A£ter_Second_SOTM_at_INS (f_history)  * 
TijDae_Out_A£ter_Second_SOTM_at_IMS  (f_hi8tory) 

V 

NRTR_Receiyed_A£ter_Second_SOTM_at_INS  ( f_history ) 

V 

NAK_Received_A£ter_Second_SOTM_at_lNS ( £_history ) 
type:  Eyent_Llst  — >  BOOL 

Rationale: 

•  Failing  a  second  attempt  to  communicate  after  a  SOTM  is  due  to  any  of  the 
following: 

•  An  INS  time  out  occurs 

•  The  EC  is  not  ready  (NRTR) 

•  The  test  message  Is  not  accepted  by  the  EC  (NAK) 
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5.6.4.1.  Time-out  After  Second  SOTM  at  INS 

Tiina_Out_A£tet_Second_SOTM_at_IMS  (£_hi8tory)  = 

Humber  Of  OutatandingSOTMaSent  at  INS (£_hi8tory)  =  2 

A 

eases  Last (£_hlstoxy) : 

(mfc-IKS  Event (ATTHl,  )  — >  true, 

T  — >  false) 

type:  Bvent_Llst  -»  BOOL 

Rationale: 

•  An  INS  time  out  of  the  EC  always  results  in  an  ATTN1  being  sent  to  the  EC 
( [14],  6.3.2.3.C,  6.3.2.1  .a(2),  6.3.6.2.a.  6.3.2.I.C.).  This  covers  time  outs  direct¬ 
ly  following  the  second  SOTM  as  welt  as  those  following  the  EOM. 

•  [14]  6.3.2.1.a  is  read  to  imply  that  ATTN1  is  issued  before  the  operator  is 
alerted. 


5.6.4.2.  Received  an  NRTR  After  Second  SOTM  at  INS 

NRTR_Receiyed_A£t«r_Second__SOTM_at_lNS  (£_history)  = 

Number_0£_Outstanding_SOTMs__Sent_at_lNS(£_history)  =  2 

A 

cases  Last (fjblstory) : 

(bJc-EC  Event  (HRTR,  )  -->  true, 

T  — >  false) 

type:  Eyent_List  -»  BOOL 

Rationale: 

•  If,  by  the  second  attempt,  the  EC  is  not  ready  to  receive  a  test  message,  the 
INS  operator  is  alerted  ( [14],  6.3.2.3.C,  6.3.2.1.b(2)). 
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5.6.4.3.  Received  a  NAK  After  Second  SOTM  at  INS 

lAK_R*e«lTttd_A£t«r_8«COnd_S0TK_«t_ZM8 (£_hlstOxy)  « 

NUinb«r_p£_Out8t«nding_SOTMa_8«nt_«t__INS  (£_hl8tory)  «  2 

A 

cases  Last (£_hi8toxy) : 

CnJc-EC  Event  (NAK,  )  — >  true, 

T  — >  £al8e) 

type:  Kvent_Ll8t  -»  BOOL 

Rationale: 

•  If.  by  the  second  attempt,  the  EC  does  not  acknowledge  the  receipt  of  a  test 
message,  the  INS  operator  is  alerted  ( [14],  6.3.2.3.C.  6.3.2.1.e). 

5.6.5.  An  Invalid  Message  or  Test  Message  Was  Received  at  INS 

Invalld_Massage_0r__Test_Me8saga_Racaivad_at_INS  (£_hlstory)  b 
£_hi8tory  ^  <> 

A 

casas  Last(£  history): 

(mk-lNS  Ks^t(HAK,  )  -->  trua, 

T  — >  falsa) 

type:  Byant_Llst  -♦  BOOL 

Rationale: 

•  Whenever  an  invalid  message  or  test  message  is  received  by  the  INS,  a  NAK  is 
sent  to  the  EC  and  the  operator  is  alerted  ( [14],  6.3.2.2.C,  6.3.2.3.b).  NAK  is 
only  issued  by  the  INS  in  the  case  of  invalid  messages. 

5.6.6.  Received  an  ATTN1  at  INS 

ATTKl_RBcaiyed_at_IKS  (£_hi8tory)  ■ 

£_hi8tory 

A 

casas  Xisst  (£_hl8tory)  : 

(nk-EC  Evant(ATTNl,  )  — >  trua, 

T  — >  falsa) 

typa:  Eyant_Llst  -*  BOOL 

Rationale: 

•  When  the  INS  receives  an  ATTN1,  It  £derts  the  INS  operator  ( [14],  6.3.6.2.d). 
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6.  Formal  Model  EC  Functions 


6.1.  Determine  If  Protocol  Is  Obeyed  at  the  EC 

Protocol_Obeyed_at__EC  (history)  (event8_at_ec)  = 

(event8_at^ec  ^  <>)  3 

(let  flr8t_event  =  M  event8_at_ec  in 
(is-gC  Event (first  event) 

Event_l8jCorrect_at_EC (history ) (fir8t_event) ) 

A 

Protocol_Obeyed_at_EC (history  *  <f ir8t_event>) (^  events_at_ec) ) ) 
type:  Event_Li8t  -»  (Event_Li8t  -♦  BOOL) 

Rationale: 

•  This  function  determines  if  the  protocol  is  obeyed  by  the  EC,  i.e.,  ensures  that 
the  EC  generates  correct  events.  Note  that  from  the  EC  perspective,  its  own 
events  are  correct  or  incorrect  and  INS  events  are  expected  or  unexpected. 

•  This  function  examines  each  event  in  a  sequence  and  determines  if  it  is  correct 
in  the  context  of  a  history. 

•  Note  that  event  filtering  does  not  take  place  within  this  function  as  it  does  in  the 
equivalent  INS  function. 

6.2.  Look  at  Each  EC  Event  in  Context  of  History 

Event_Is_Corr«ct_at_EC  (history)  (ec_avant)  = 

let  nh-EC  Event (event  Info,)  =  ec_event  in 
(is-Comms  Event (event_in£o)  — > 

Comma  Event_Is_Correct_at_EC (history) (ec_event) , 


T  — > 

let  £__hi8tory  «  Filter_Event_Li8t_at_EC  (history)  in 
Non_Comms__Event_l8_Correct^at__EC(f_history)  (ec_event) ) 

type:  Eyent_Li8t  -»  (EC_Eyent  — »  BOOL) 

Rationale: 

•  This  function  separates  the  treatment  of  communications  events  and  noncom¬ 
munications  events. 

•  Filter_Event_IJst_at_EC  removes  unexpected  INS  events  (caused  by  transmis¬ 
sion  errors  or  incorrect  INS  behavior),  thus  simplifying  the  event  stream  that 
needs  to  be  examined.  In  essence  this  process  removes  INS  events  that  the 
EC  may  ignore.  It  is  only  done  when  the  current  event  is  an  EC  non¬ 
communication  event,  since  out-of-sequence  INS  EFs  may  cause  the  EC  to 
respond  with  an  ATTN1 . 
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6.2.1.  Look  at  Each  EC  Communications  Event  in  Context  of  History 

Conmis_Event_Is_Correct_at_EC  (history)  (ec_event)  - 

let  mk-EC  Event (event  info,)  =  ec_event  in 

(is-EF  Event (event_info)  — > 

EF_Event_Is_Correct_at_EC (history) (ec_event) , 

is-Data  Message (event  info)  — > 

let  f_history  =  Filter_Event_Liat_at_EC (history)  in 
Data_Event_Is_Correct_at_EC (f_history) {ec_event) ) 

type:  Event_List  —*  (EC_Event  ^  BOOZi) 

Rationale: 

•  This  function  separates  the  treatment  of  EF  events  and  data  events. 

•  Filter_Event_List_at_EC  removes  unexpected  INS  events  (caused  by  transmis¬ 
sion  errors  or  incorrect  INS  behavior),  thus  simplifying  the  event  stream  that 
needs  to  be  examined.  In  essence  this  process  removes  INS  events  that  the 
EC  may  ignore.  It  is  only  done  for  data  messages,  since  out-of-sequence  INS 
EFs  may  cause  the  EC  to  respond  with  an  ATTN1 . 
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6.2.1 .1.  Look  at  Each  EC  Communications  EF  Event  in  Context  of  History 

Er_Event_I»_Correct_«t_BC(hi8tory)  (ac_event)  = 

let  mlc-EC  Event  (event  Info,  event  tiine)  =  ec_event  ^ 
if  event__info  =  ATTKl  then 

ATTMl_l8_Correct_et_EC (history) (event_tiae) 
else 

let  f_hi8tory  =  Pilter_Event_Li8t_at_EC (history)  in 
cases  e^ent_info: 

(ACK  “> 

ACK_l8_Correct_at_BC  (f_hi8tory)  (event_tiine) , 

ATTW2  — > 

ATTN2_Is_Correet_at_EC(f_hi8tory)  (event_tinie) , 

ATTN4  — > 

ATTM4_l8_Correct__at_EC(f_history) , 

EOM  — >  “ 

Ea4_Is_Correet_at_EC (£_hi8tory) (event^tine) , 

KAK  — > 

MAK_Is_Correct_at_BC(£_hi8tory)  (event_tiine) , 

MRTR  ~  — > 

NRrR_l8_Correct_at__EC(£_hi8tory)  (event_tiine) , 

RTR  — > 

RTR_la_Correct_at_EC(£_hi8tory) (event_time) , 

SOM  — >  ~ 

SC»l_Ia_Correct_at_EC(£_history)  (event_tiine) , 

SOTM  — > 

SOTM_Ia_Correct_at_EC(£_history)  (event_tijne) , 

Error  EF  --> 

false) 

type:  Event_List  — »  (INS_JEvent  ^  BOOL) 

Rationale: 

•  This  function  divides  EF  events  into  the  individual  EFs  and  invokes  functions  to 
express  the  conditions  for  the  individual  EFs. 

•  Filter_Event_Ust_at_EC  removes  unexpected  INS  events  (caused  by  transmis¬ 
sion  errors  or  incorrect  INS  behavior),  thus  simplifying  the  event  stream  that 
needs  to  be  examined.  In  essence  this  process  removes  INS  events  that  the 
EC  may  ignore.  It  is  done  for  all  EC  EFs  except  ATTN1,  since  out-of-sequence 
INS  EFs  may  cause  the  EC  to  respond  with  an  ATTN1 . 
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6.2.1 .2.  Look  at  Each  EC  Data  Event  in  Context  of  History 

Data_Event_Is_Correct_at_EC(f_hiatory) (ec_event)  =  # 


let  mk-EC  Event (event  info,  )  =  ec_event  In 
(is-Test  Msg (event_inf o)  — > 

Teat_Msg_Is_Correct_at_EC(£_history) (ec_event) , 

ia-Select  Data  Mag (event_in£o)  — > 

Select_Data_M3g_Ia_Correct_at_EC (£_hiatory) (ec_event) , 


T  -~> 

falae) 

type:  Event_Liat  -»  (EC_Event  -*  BOOL) 

Rationale: 

•  This  function  separates  the  treatment  of  test  messages,  select  data  messages, 
and  other  messages  (the  latter  are  never  correct  data  events  from  the  EC). 

6-2.2.  Look  at  Each  EC  Non-Communications  Event  in  Context  of  History 

Non_Conim3_Event_Ia_Correct_at_EC{£_hiatory)  (ec_event)  = 

let  ink -EC  Event  (event  in£o,  )  =  ec_event  in 
(ia-Siqnal  £rom  EC  Operator (event_in£o)  — > 
Signal_£rom_EC_Operator_la_Correct_at_EC, 

T  — > 

Signal_to_EC_Operator_IajCorrect_at_EC (£_hi8tory) ) 

type:  Event_Li8t  —>  (ECJEvent  =4  BOOL) 

Rationale: 

•  This  function  separates  the  treatment  of  signals  from  and  to  the  EC  operator. 

6.2.2.I.  Look  at  Each  EC  Signal  from  the  Operator  in  Context  of  History 

S  ignal_£roni_EC_Operator_1 8_Correct_at_EC  = 
true 


type :  BOOL 

Rationale: 

•  The  behavior  of  the  EC  operator  is  part  of  the  environment  of  the  system  and 
outside  its  control.  • 
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6.2.2.2.  Look  at  Each  EC  Signal  to  the  Operator  in  Context  of  History 

Signal_to_EC_Oper«tor_la_Cortect_at_EC  (£_history)  = 


type:  Event_Li8t  — »  BOOL 

Rationale: 

•  The  EC  may  send  signals  to  its  operator.  The  specification  of  when  such  sig¬ 
nals  occur  is  not  part  of  the  communication  protocol. 

6.3.  Filter  Event  List  at  EC 

Filter_Event_Liat_at_EC  (eventa_at_ec)  = 

Remove_Une3epected_IHS_Event8 (<>) (event8_at_ec)  —  6.3.6.1.C 
type:  Event_Liat  — ♦  Eyent_Liat 

Rationale: 

•  Out-of-sequence  INS  EFs  can  be  ignored,  except  when  considering  the  legality 
of  an  EC  ATTN1. 

6.3.1 .  Remove  Unexpected  INS  Events  at  EC 

Remoye_Unexpected_EC_Events (history) (event  s_at_ec)  = 

( event  a_at_ec  ^  O  — > 

(let  first_event  =  hd  events_at_ec  in 
(is-INS  Event (f irst_event)  a 

is -Congas  Event (s-INS_Event_Info (£irst_event) )  — > 

(Congns_Event_Is_Correct_at_INS  (history)  (f  irst_event)  — > 
Reniove_UneJcpected_INS_Events  (history  ^  <£irst_event>) 

(tl  event s_at_EC) 

T  — > 

Reinove_Unexpected_INS_Events (history) (tl  events_at_ec) ) , 


T 


— > 

Reniove_Unej(pected_EC_Events  (history  <£irst_event>) ) , 

(tl  event s_at_ec) 


T 


— >  history) 


type:  Event_List  -♦  (Event_Li8t  -»  Event_Li8t) 

Rationale: 

•  Out-of-sequence  INS  EFs  are  defined  as  those  not  satisfying  the 
"INS  correctness." 
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6.4.  Determine  Correctness  of  Individual  EC  EF  Events 


6.4.1.  ACK 

ACK_ls_Correct_at_EC(f_hi8tory)  (ack:_tiae)  ■ 

cases  Last_n  (2 , £_hlstoxy) : 

«mk-lMS  Event  (data_Bi8g,  ) , 
ndc-INS  Event  (BOM.  eom_tliDe)  >  — > 

ValldJData_Hes8age  (data^Bisg)  —  6.3.2.1.d 

A 

ack_tljoe  -  eom_tlae  £  Tliiie^Oat_Period_at_IMS,  —  6. 2. 3. 2. a 
T  — >  ~ 

false) 

type:  Event_X>lst  -»  (Tliaa_Staiiip  — >  BOOI.) 

Rationale: 

•  The  EC  acknowledges  the  receipt  of  a  message  (responds  with  an  ACK)  after 
the  corresponding  EOM  if  the  message  is  valid. 

•  The  ACK  response  must  occur  before  the  INS  time-out  period  associated  with 
the  EOM. 

6.4.2.  ATTN1 

ATTNl_ls_Correct_at_EC  (history)  (attnljtiae)  « 
history  *  <> 

A 

(^-INS_Event  (Last  (history) )  — >  —  6.3.6.1.C 

INS_EP_l8_Out_0£_Sequence_at_EC (Front (history) ) (Last (history) ) , 

T  — >  —  6.3. 6.1. a 

let  mlt-EC  Eventdast  event,  last  event  time)  »  I.a8t (history)  In 
la8t_eyent  e  (RTR,  SOM,  SOTMl 

A 

attnl_tiiDe  -  last  event  tljne  >  Tine  Out  Period  at  EC) 


type:  Eyent_Llst  — »  (Tlme_Staiip  -»  BOOL) 

Rationale: 

•  An  ATTN1  from  the  EC  is  either  the  response  to  an  INS  EF  that  is  received  out 
of  sequence,  or  to  the  EC  timing  out  the  INS  In  cases  where  a  timely  response 
is  required  (after  RTR,  SOM  or  SOTM,  but  not  after  EOM  as  at  the  iNS; 
[14]  6.3.2.1  .b,  6.3.2.2.a,  6.3.2.3.a). 

•  Note  that  the  INS_EF_ls_Out_Of_Sequence_at_EC  function  is  true  for  histories 
that  include  periodic  messages  that  do  not  satisfy  the  required  periodicity. 
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6.4.2.I.  Detect  out  of  Sequence  INS  EF  Events  at  EC 

lMS_Kr_l8_Out_0£_S«qu«nc«_«t_EC  (history)  (lns_«v«nt)  • 

let  £_hl8tory  *  Flltex_Event_Llst_8t_BC (history)  In 
let  aJc-INS  Event (lest  event,  )  »  lns_eTent  in 
is-ET  Event (last^event) 

A 

-1  EF_Event_l8_Correet_st_lNS(£_hi8tory) (ln8_event) 
type:  Event_Li8t  -»  (XMS_Event  ->  BOOL) 

Rationale: 

•  For  an  INS  event  to  be  an  out-of-sequence  EF  (at  the  EC),  it  must  (obviously) 
be  an  EF  event,  and  secondly  it  must  be  Incorrect  when  seen  as  an  event  at 
the  INS,  given  the  history  as  seen  by  the  EC  [14]  (6.3.6.1.C). 


6.4.3.  ATTN2 

ATTN2_l8_Correct__st_EC(£_hi8tory)  (ettn2_tljae)  ■ 

Ensbling_Reque8ted_at_EC  ( £_history ) 

A 

Initiating_Er_Mot_Too__Soon_at_EC(£_hl8tory)  (attn2_tijne)  —  6.2.3.2.b 
type;  Eyent_Li8t  -»  (Tiaie_Staii^  ->  BOOL) 

Rationale: 

•  ATTN2  is  issued  by  the  EC  as  the  first  EF  In  an  enabling  sequence  ([14], 

6.2.1  .b  and  p.  5-2).  Hence,  enabling  must  have  been  requested  by  the  EC  op¬ 
erator. 

•  ATTN2  falls  into  the  category  of  initiating  EFs  (which  includes  SOM  and  SOTM 
as  well),  and  no  more  than  two  of  such  EFs  are  allowed  per  second. 
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6.4.3.1.  No  More  Than  Two  Initiating  EFs  per  Second  from  the  EC 

Initiating_EF_Not_Too_Soon_«t_EC(£_history)  (current_tijiie)  * 

(V  i,j  6  ind  £_hi8tory) 

( (ia-EC  EvantCf  hlatoryfi] )  a  la-EC  Event (£  history [j]) 
A  i  <  j 

A  current_tijne  -  8-Tlioe_StaiBp(£_hlstory[l] )  ^ 
Min_Inltiating_Palr_Separation_Tlme  ) 

(let  adc-EC  Event  (event  in£o  L,  )  *»  £_history[i]  in 
let  adc-EC  Event (event_ip£o_i ,  )  «  £_history[j]  ^ 
-1  (event  ln£o  i,event_ln£o  i>  c 

(SOM, SOTM,ATTN2} ) ) 


type:  Event_Ll8t  -*  (Time_Staap  — >  BOOL) 

Rationale: 

•  No  more  than  two  initiating  EFs  (i.e.,  SOM,  SOTM  or  ATTN2)  may  occur  within 
one  second  [14]  (6.2.3.2.b). 

•  This  means  that  for  any  two  previous  EC  events  (from  the  history)  that  hap¬ 
pened  within  that  period,  they  cannot  both  fall  into  this  category  of  initiating 
EFs. 

6.4.3.2.  Enabling  has  been  Requested  by  the  EC  Operator 

Enabllng_Reguested_at_EC  (£_hi8tory)  = 

£_hiatory  #  O 

A 

(1£  Is-EC  Event (Last (£  hlatorv) )  then 

8-EC_Event_ln£o (Last (£_hlstory) )  g  Enable  Coaans 

else  Enabllng_Beque8ted_at_EC (Front (£_hi8tory) ) ) 

type:  Event_Ll8t  -♦  BOOL 

Rationale: 

•  The  last  EC  event  in  the  history  must  be  an  operator  request  for  enabling  com¬ 
munications. 
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6.4.4.  ATTN4 

ATTN4_l8_Correct_at_EC(f_history)  = 

Disabling_Requested_at__EC  (£_hlatory) 
type:  Evant_Li8t  -♦  BOOL 

Rationale: 

•  ATTN4  from  the  EC  is  the  EF  used  to  disable  communication.  ATTN4  can  be 
issued  whenever  the  EC  operator  requests  it  [14]  (6.2.2.a). 


6.4.4.1.  Disabling  has  been  Requested  by  the  EC  Operator 

Di8abling_Reque8ted_at_EC (£_hi8tory)  « 

£_hi8tory  *  <> 

A  . 

(if  i8-EC  Event (La8t(fhl8torvn  then 

8-EC_Event_ln£o(Iia8t  (£_hi8tory) )  =  Di8able  Coimns 
•l8e  Ol8abllng_Reque8ted_at_TC (Front (£_hi8tory) ) ) 

type;  Event_Ll8t  BOOL 

Rationale: 

•  The  last  EC  event  In  the  history  must  be  an  operator  request  for  disabling  com¬ 
munications. 

6.4.5.  EOM 

EOM_l8_Correct_at_EC (£_hi8tory) (eom_tixne)  = 

08888  La8tja(2,  £__hl8tozy)  : 

«ink-INS  Event  (RTR,  rtr_tlae) , 
nk-EC  Event (ec  info.  )>  — > 
i8-Data  Meeeaqe (ec_in£o) 

A 

eom_tiine  -  rtr_tiine  <  Tiiae_Out_Period_at_INS ,  —  6.3.2.2.b 
T  — > 

false) 

type:  Eyent_Li8t  -»  (TiiBe__Staiip  BOOL) 

Rationale: 

•  An  EOM  must  follow  a  data  message  from  the  EC  [14]  (6.2.3.2). 

•  It  must  be  issued  before  the  INS  times  out  the  EC. 
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6.3.2.1.d 


6.4.6.  NAK 

NAK_Is_Correct_at_EC(f_history)  (nakjtiine)  = 


cases  Last_n(2, £_history) : 

«in3c-IMS  Event  (data_aisg,  ) , 
mlc-INS  Event  (ECTt,  eom  tiine)>  — > 

-I  ValidJData_Message  (data_iiisg) 

A 

nak_tl8ie  -  eom_tiJBe  S  Tline_Out_Period_at_INS ,  —  £.2. 3. 2. a 
T  — > 

false) 

type:  Event_Llst  —*  (Tiine_Staxnp  BOOL) 

Rationale:  • 

•  When  a  message  has  been  received  from  the  INS  (terminated  by  an  EOM)  and 
the  validity  check  of  the  message  fails,  the  EC  responds  with  a  NAK. 

•  The  EC  must  issue  this  response  before  it  is  being  timed  out  by  the  INS. 


6.4.7.  NRTR 

NRTR_Is_Correct_at_EC(£_history)  (nrtr_tiiaa)  * 

£_history  <> 

A 

-I  Data_Bu£fer_ls_R«ady_at_EC<£_hlstory>  —  6.3.2.1.b  # 

A 

cases  Last (f_hl8tory) : 

<^-INS_Bvent  (S^,  8om_tiJBe)  --> 

nrtr_jtiJiie  -  80in__tiine  S  Tiine_Out_Period_at_IKS ,  —  £.2. 3. 2. a 

nJc-IKS  Event  (SOTM,  80tai_tiiae)  — > 

nrtr_tline  -  80tm_tiiiie  <  Tijne_Out_Period_at_INS ,  —  £.2. 3. 2. a  ^ 

T  — > 

false) 


type:  Event^Llst  -»  (Tiiae_^Staitp  BOOL) 

Rationale: 

•  An  NRTR  signals  that  the  data  buffer  at  the  EC  is  not  ready. 

•  An  NRTR  must  follow  either  an  SOM  or  an  SOTM  from  the  INS,  and  do  so 
before  the  EC  is  timed  out  by  the  INS. 
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6.3.2.1.b 


RTR_l8_Correct_«t_EC(£_hi8tory)  (rtrjtlma)  = 

£_hi8tory  ^  <> 

A 

D8t  a_Bu££ez_1 8_Il8ady_at_EC  ( £_hl8tozy ) 

A 

caaea  Laat (£_hl8tozy) : 

(mk-INS  Event  tSOH.  80m_tl]&e)  — > 

rtr_tijne  -  8am_tijne  <  Tijne_Oat_Period_at_INS ,  —  €.2. 3. 2. a 

adc-INS  Event  (SOTM,  80tm_tline)  — > 

ztr_tl8>e  -  80tia_tixtie  ^  rlaie_Out_Period_at_IMS,  —  6. 2. 3. 2. a 
T  — > 

£alae) 

type:  Event_Ll8t  -»  (Tlme_Staiap  -*  BOOL) 

Rationale: 

•  An  RTR  signals  that  the  data  buffer  at  the  EC  is  ready. 

•  An  RTR  must  follow  either  an  SOM  or  an  SOTM  from  the  INS,  and  do  so  before 
the  EC  is  timed  out  by  the  INS. 

6.4.8.1.  Determine  whether  the  EC  Data  Buffer  is  Ready 

Data_Bu££ar_l8_R«iady_atJEC (£_hiatory)  «= 


type:  Event^Liat  ->  BOOL 

Rationale: 

•  [14]  does  not  define  when  the  EC  data  buffer  is  ready.  The  function  is  included 
in  the  model  because  the  availability  of  a  buffer  affects  certain  EC  responses 
(RTR  and  NRTR). 

6.4.9.  SOM 

SOM_l8_Correct_at_EC(£__hi8tory)  (8om__tiine)  = 

CoBODunlcat  lon8_are_Enabled  ( £_hl8tory) 

A 

lnitiating_EF_Not__Too_Soon_at_EC  (£_hi8tory)  (80ia_tiine) 

A 

Select_pata_He88age_Reque8ted(£_blatory) 
type:  EventJLlat  ->  (Tlaui_StaBip  -»  BOOL) 

Rationale: 

•  An  SOM  can  only  be  sent  after  communications  have  been  enabled. 
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•  SOM  falls  into  the  category  of  initiating  EFs  {which  includes  SOTM  and  ATTN2 
as  well),  and  no  more  than  two  such  EFs  are  allowed  F>er  second. 

•  SOMs  are  only  used  by  the  EC  to  initiate  the  sending  of  a  select  data  message. 
Therefore,  a  select  data  message  must  have  been  requested  by  the  operator 
before  the  EC  issues  an  SOM. 


6.4.9.I.  Communications  are  Enabled 

Coimnunlcatlons_are_Enable<l(£_hi8toxy)  = 


Enda  ln_EnabllnQ_Sequence (fhlatory)  —  6.2.1.a-e 

V 

(£__hi8tory  *  O 

A 

eaaea  Laat (£_bl8tory) : 

(mfc-EC  Event ( ATTW2 ,  )  — >  false, 
mk-EC  Event (ATTW4,  )  — >  false, 

T  — > 

Coinmunicatlons_are_Enabled (Front  (£_hlstory)  n  ) ) 

type:  Event_Li8t  — »  BOOL 

Rationale: 

•  Communications  are  enabled  if  the  event  sequence  contains  an  enabling  se¬ 
quence,  and  there  are  no  later  ATTN2s  or  ATTN4s  from  the  EC  after  the  last 
enabling  sequence. 


6.4.9.2.  A  Select  Data  Message  must  have  been  Requested 

Select_Oata_He8sage_Requested  (£_blstory)  s 


f_hiatory  *  O 

A 

(if  is -EC  Event (Last (f_hi8tory) )  then 

let  mk-EC  Event (ec  info,  )  *  Last (£_bi8tory)  in 
ec_in£o  e  (Select  Attitude,  Select  Navigation, 
Select  None,  Select  Both) 

else  Select_Data_Message__Requested (Front (f_hi8tory} ) 
type:  Eyent_Li8t  — »  BOOL 

Rationale: 


•  The  last  EC  event  in  the  history  must  be  an  operator  request  for  sending  a  se¬ 
lect  data  message. 
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6.4.10.  SOTM 

SOTM_l8_Corr«ct_«t_EC(£_hi8tory)  (80t]&_tiin8)  « 

f_hi8tory  *  O 
A 

lnitiating_EF_Hot_Too_Soon_«t_EC  (f_hi8tory)  (8otiii_tiiiie) 

A 

08888  L88t (£_hi8tozy) : 

(mlc-INSEvent  (ATTM2, 8ttn2_tiin8)  — > 

80tm_tijBe  -  8ttn2_tia8  ^  Tiiiie_Out_Perlod_at_ZNS,  —  6.2.1.c-d 
T  — > 

CooBDunlca  t  lon8_a  re_Enabl8d  ( £_hl8 1  o  ry ) 

A 

T88t_Me88ag8_Reque8t8d(£_hl8tory) ) 
type:  Event_Li8t  -»  (Tline_Staiqp  ->  BOOL) 

Rationale: 

•  SOTM  falls  into  the  category  of  initiating  EFs  (which  includes  SOM  and  ATTN2 
as  well),  and  no  more  than  two  of  such  EFs  are  allowed  per  second. 

•  Moreover,  the  SOTM  must  either: 

•  follow  an  ATTN2  from  the  INS  (as  part  of  enabling  the  communications), 
or 

•  have  been  explicitly  requested  by  the  EC  operator  (in  which  case  com¬ 
munications  must  have  been  enabled). 

6.4.10.1.  Determine  If  a  Test  Message  has  been  Requested  by  the  EC  Operator 

Test_Me88age_Reque8ted(£_hl8tory)  k 
£_hiatory  ^  <> 

A 

(if  ia-EC  Event (Laat {f_hi8tory) )  then 

s-EC_Eyient_In£o  (Laat  <£_hi8tory) )  =  Send  Test 
else  TestJMessage^Reguested (Front (£_hlstory) } ) 

type:  Event_Li8t  -*  BOOL 

Rationale: 

•  The  last  EC  event  in  the  history  must  be  an  operator  request  for  sending  a  test 
message. 
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6.5.  Determine  Correctness  of  Individual  EC  Data  Message  Events 


6.5.1.  Test  Message 

Test_Msg_l8_Correct_*t_EC(f_hi8tory)  (•c_«v«nt)  ■ 

let  ink-EC  Bvent(te8t  msQ,  )  •  ec_event  In 
08888  Iia8t_n  (2 ,  f_hlstory) : 

«in)c-EC  Event  (SOTM,  ) , 

mk-IKS  Event  (RTR,  )  >  — >  V8lld^Dat8_lie888ge  (te8t_m8g} , 
T  — >  false) 


type:  Event_ti8t  -»  (EC_Event  BOOZ>) 

Rationale: 

•  A  test  message  can  only  be  sent  to  the  INS  if  the  INS  is  ready  to  receive  a  test 
message  [14]  (6.3.2.3.a  and  6.3.2.2.b). 

•  The  test  message  must  be  valid  when  sent. 


6.5.2.  Select  Data  Message 

SelectPataMsgls  Correct  at  EC(£  history) (ee_event)  « 


cases  £_hi8tory: 

(£__hi8toryj»re£ix 


-qnJt-EC  Event  (SOM,  ), 
nJc-INS  Event  (RTR.  )>  — > 
let  nlc-EC  Event  (selectjdatajnsg,  event_tiae) 
Valld_pata_Me88age  (8eiect_daitajBsg) 


*  ec  event  in 


Corre8pondlng_Select_Pata_Meq_Eaque8ted(f  history  prefix) 

(8elect_data_insg) 

A 

Select_Data_Msg_Not_Too_Often_at_EC(f_hi8tory) (event_tiaie) 

— > 

false) 


type:  Event_Li8t  -»  (EC_Event  ^  BOOL) 

Rationale: 

•  A  select  data  message  can  only  be  sent  to  the  INS  if  the  INS  is  ready  to  receive 
such  a  message  ( [14],  6.3.2.2.a-b). 

•  The  select  data  message  must  be  valid. 

•  The  select  data  message  must  specify  the  selection  of  data  requested  by  the 
EC  operator. 

•  Select  data  messages  must  not  be  sent  too  often  (more  than  once  per  second). 
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6.5.2.1.  The  Corresponding  Select  Data  Message  Must  have  been  Requested 

Correspondlng_Select_Data_M8g_Reque8ted(£_hl8tory) (8elect_data_insg)  = 
f_hi8tory  ^  <> 

A 

(if  l8-gC  Event  (Iia8t  (f  hlatorv)  >  than 

let  mlc-EC  Event  (ee  Info,  )  »  Lent  (£_hi8tory)  In 

let  8elected_iii8g_type  =  s-Selected_Mag_Type(8elect_data_in8g)  in 

caaea  8elected_in8g_type : 

(Attitude  — >  ec_in£o  *  Select  Attitude. 

Mavigation  — >  ee_in£o  =  Select  Kavigation. 

None  — >  ec_in£o  “  Select  None, 

Both  — >  ec_in£o  “  Select  Both) 

elae  CorreapondlngSelect_Data_MagReque8ted (Front (£_hi8tory) ) 

(8elect_data_m8g) ) 


type;  Event_Id.8t  (Select_pata_M8g  -»  BOOL) 

Rationale: 

•  The  select  data  message  sent  to  the  INS  must  reflect  the  selection  specified  by 
the  EC  operator.  The  last  EC  event  must  be  an  operator  request  for  sending  a 
select  data  message. 

6.5.2.2.  No  More  than  One  Select  Data  Message  from  the  EC  per  Second 

Select_Data_Mag_Not_Too_p£ten__at_EC(£_hl8tory)  (time__8taiiip)  = 

-I  (3  i  e  ind  £_hi8tory) 

(la -EC  Event (£_hi8tory [1] ) 

A 

la -Select  Data  Mag (8-EC_Event__In£o (£_hi8tory [1] ) ) 

A 

tiine_8taa^  -  8-Tlxne_Stasap(£_hl8tory[l] }  < 

Mln_Select_Dat  a__Separat  lon_t  ime } 


type:  Eyent_Ll8t  -♦  (Tliiie_StaBp  BOOL) 

Rationale: 

•  No  more  than  one  select  data  message  is  allowed  per  second,  i.e.,  no  (other) 
select  data  message  can  have  occurred  within  the  last  second  ( [14],  pg.  8-10). 
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7.  Formal  Model  General  Functions 


7.1.  Auxiliary  Functions 


7.1.1.  Determine  If  a  Data  Message  is  Valid 

Valid_Data_Message  (data_iasg)  = 

(data_m3g  =  Error  Data  Message  — >  false, 

T 

type:  Data_Hessage  ->  BOOL 

Rationale: 

•  This  function  validates  the  correctness  of  data  messages  at  the  INS  and  at  the 
EC. 

•  However,  its  detailed  specification  is  not  part  of  the  communication  protocol  and 
hence  is  considered  to  be  outside  the  scope  of  this  effort. 
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7.1.2.  Determine  If  the  History  Ends  in  an  Enabling  Sequence 

Ends_in_Enabling_Sequence  (f_hi8tory)  = 

cases  Last_n (3, £_history) ;  — 6.2.1.d-e 

{  <  nk-INS  Event (mk-Test  Msg (  ) ,  ) , 

^-INSJEvent  (EW,  ) , 

mk-EC  Event (ACK,  )  >  — >  true, 

T  — >  false  ) 


(3  i  e  Ind  f_history) 

(  cases  f_history[i] : 

(  mk-lNS  Event (ATTN2,  ) 

T 

A 

(V  j  e  {kl  k  €  Ind  £_history  a  k  >  i  )  ) 

(  cases  £_history[ j] ; 

(  mk-INS  Event (ATTN2,  )  — >  false, 

T  — >  true  )  ) 

A 

(V  j  e  {k|  k  e  Ind  £_history  a  k  >  i  a  k  S  (len  £_history) -2-3}  ) 
(  cases  <  £_history[m]  |  j  <  m  <  j+2  >: 

(  <  mk-INS  Event  (mk-Test  insq(  ),  ), 
mk-INS  Event (EOM,  ) , 
mk-EC  Event  (ACIC,  }  >  — >  false, 

T  — >  true  )  ) 

type:  Event_List  -♦  BOOL 

Rationale: 

•  Regardless  of  retries,  a  successful  enabling  sequence  must  end  in  the  in¬ 
dicated  sequence  of  EFs. 

•  Moreover,  there  are  no  ATTN2s  or  ATTN4s  after  the  ATTN2|(^5  that  was  issued 
in  response  to  the  EC  initiation  of  communications  via  ATTN2£q.  Note  that  this 
function  employs  the  knowledge  that  the  only  correct  EF  to  follow  an  ATTN4  is 
an  ATTN2£q  and  an  ATTN2|ns  can  only  follow  an  ATTN2£q. 

•  Moreover,  the  only  subsequence  after  the  ATTN2||gs  consisting  of  Test-Msg|fgs. 
EOM|f^s>  ACKgQ  is  the  last  three  events. 


— 6.2.1. c-e 

— >  true, 

• — >  false  ) 
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7.1.3.  Number  of  SOMs  Sent  from  the  INS  and  Still  Outstanding 

Kianber_Of_Outstanding_SOMs_Sant_at_lNS  (£_history)  = 

if  f_history  ^  <>  then 
cases  Last (£_history) : 

(mlc-EC  Event  (last_event,  )  — > 

(last_event  e  {ACK,  ATTM2,  ATTN4,  S^,  SOTO)  — >  0,  —  6.3.2.1.e 
T  — > 

Nuinber_0£_Outstanding_SOMs_Sent_at_INS  (Front  (£_history) ) ) , 
mk-INS  Event (last  event.  )  — > 

(last_event  =  SOM  — > 

1  +  Nuinber_O£_Outstanding_S0Ms_S6nt_at_INS  (Front  (£_history) ) , 
Is-Slgnal  to  INS  Operator (last  event)  — >  0, 

T  — > 

Nuinber_0£_Outatanding_STOs_Sent_at_IMS (Front (£_history) ) ) ) 

else  0 

type:  Event_List  NO 

Rationale: 

•  Yields  the  number  of  SOMs  issued  by  the  INS  for  non-terminated  messages. 


7.1.4.  Number  of  SOTMs  Sent  from  the  INS  and  Still  Outstanding 

Nuinber_jOf_Outstanding_SOTOs_Sent_at_INS  (fjhistory)  = 

if  £_history  <>  then 
cases  Last (£_history) : 

(mk-EC  Event (last  event,  )  — > 

(last_event  e  (A^,  ATTN2,  ATTN4,  SOM,  SOTO)  — >  0,  —  6.3.2.1.e 
T  — > 

Nuniber_Of_Outstanding_SOTOs_Sent_at_IMS  (Front  (f_history) ) ) , 
mk-INS  Event (last  event.  )  — > 

(last_event  =  SOTO  — > 

1  +  Nuinber_0£_Outstanding_SOTOs_Sent_at_lNS (Front (f_history) ) , 
is-Siqnal  to  INS  Operator (last  event)  — >  0, 

T  — > 

Nuinber_Of__Outstanding_SOTOs_Sent_at_INS  (Front  (£_history) ) ) ) 

else  0 

type:  Event_List  — »  NO 

Rationale: 

•  Yields  the  number  of  SOTMs  issued  by  the  INS  for  non-terminated  test  mes¬ 
sages. 
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7.2.  Constant  Functions 


7.2.1.  Constant  Function  for  INS  Time-Out  Period 

Tiine_Out_Period_at_lNS  = 

1024  —6. 2. 3. 2. a 

type :  — »  N1 

7.2.2.  Constant  Function  for  EC  Time-Out  Period 

Tiine_Out_Period_at_EC  = 

800  — 6. 3.2.1. b 

type:  — »  N1 

7.2.3.  Constant  Function  for  Sleep  Period 

Sleep_Period  * 

512  — 6.3.2.1.b.l 

type:  — »  N1 

7.2.4.  Constant  Function  for  Attitude  Period 

Attitude_Period  * 

6144  — pg.  8-36 

type:  -»  HI 

7.2.5.  Constant  Function  for  Navigation  Period 

Naylgatlon_Perlod  <= 

98304  — pg.  8-24 

type:  — »  HI 
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7.2.6.  Constant  Function  for  the  Period  Within  Which  No  More  Than  One  Seiect 
Data  Message  May  Occur 

Mln_Select_Data_Separatlon_Tline  «■ 

100000  --  p9.  8-10 

type:  Ml 

7.2.7.  Constant  Function  for  the  Period  Within  Which  No  More  Than  Two 
Initiating  EC  EFs  May  Occur 

Mln_Inltlatlng_Palr_Separatlon_Tima  > 

100000  "  6.2.3.2.b 

type:  — »  Ml 

7.3.  Tuple  Manipulation 

7.3.1.  Get  Last  Event  in  Event  List 

Z^aat  («yttnt__ll8t)  « 

ey«nt_llst[  len  •yent_ll8t] 
type;  Byent_Ll8t  ^  By«nt 
pre;  •yent_ll8t  ^  O 

7.3.2.  Get  Last  n  Events  in  Event  List 

Iia8t_n  (n,  •yttnt_ll8t)  « 

(  n  <  len  eyent_llst  — > 

<  event_ll8t [1]  |  (len  eyent_llst  -  n  +  1)  Si 

A 

1  S  len  eyent_ll8t  >, 

n  ^  len  event_li8t)  — >  eyent_li8t  ) 

type:  MO  Byent_Llst  ->  Byent_Zii8t 
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7.3.3.  Get  All  Events  Except  Last  One  In  Event  List 

Front (event_list)  = 

<  event_list [i]  |  1  <  i  ^  len  event_list  -  1> 
type:  Event_Llst  -»  Event_Ll8t 
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8.  Issues  in  Formal  Specification  of  Communication 

•  Protocols 

This  chapter  discusses  several  issues  pertinent  to  formalizing  communication  protocols.  Its 
purpose  is  to  illustrate  how  formal  specification  allows  certain  issues  to  be  addressed,  and 
how  different  specification  techniques  within  our  approach  are  used  to  address  these  issues. 

•  It  is  not  intended  to  be  a  comprehensive  survey  of  formal  approaches  to  defining  communi¬ 
cation  protocols;  such  a  survey  can  be  found  in  [7]. 

Specification  methods  that  have  been  applied  to  communication  protocols  can  be  divided 
into  three  major  categories  [10, 5]: 

•  1 .  T  ransition  models 

2.  Programming  language  models 

3.  Hybrid  models 

Transition  models  define  protocols  by  specifying  the  behavior  of  each  communicating  entity 

•  in  response  to  events.  Examples  of  transition  models  are:  finite  state  machines  [8, 6];  formal 
languages/grammars  [11];  and  Petri  nets  [8, 1].  Programming  language  models  describe  a 
protocol  as  an  algorithm  and  define  the  aJgorithm  in  a  high-level  language;  an  example 
is  [9].  Hybrid  models  extend  transition  models,  typically  finite  state  machines  or  Petri  nets, 
by  introducing  variables  to  limit  the  number  of  different  states,  and  thereby  avoid  the  prob- 

•  lem  of  getting  unworKably  large  state  machines  (a  problem  known  as  state  explosion); 
see  [8, 1 0]  for  examples. 

Our  model  can  be  characterized  as  a  hybrid  model.  However,  it  differs  from  the  traditional 
hybrid  models  in  that  it  is  not  based  on  a  state  machine  approach  but  on  a  formal  language 
^  approach.  The  type  equations  for  event  sequences,  events,  etc.,  define  a  formal  language 

or  grammar  describing  part  of  the  systems  behavior,  and  the  set  of  Boolean  functions  further 
restrict  the  set  of  event  sequences  defined  by  the  type  equations.  The  event  sequences 
that  obey  the  protocol  constitute  the  language. 

A  formal  definition  of  a  communication  protocol  can,  due  to  its  unambiguous  interpretation, 
^  serve  several  purposes.  It  can  be  used  to  validate  the  protocol  [5, 10]  and  as  a  basis  for  an 

implementation  [5, 8j.  These  two  roles  of  a  formal  protocol  specification  are  further  dis¬ 
cussed  below. 

Protocol  Validation 

•  The  activities  involved  in  ensuring  that  a  system  satisfies  its  design  specification  and  that  it 
operates  according  to  what  the  user  expects  is  normally  referred  to  as  system  validation. 
Verification  is  a  part  of  validation  that  can  be  achieved  by  formal  reasoning  about  interesting 
properties  of  the  system.  In  the  case  of  communication  protocols,  the  properties  that  one 
might  be  interested  in  verifying  include  [5. 10]: 

•  •  the  absence  of  deadlocks 
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•  completeness  (all  possible  inputs  accepted) 

In  state-based  protocol  definitions,  the  absence  of  deadlock  is  normally  shown  by  perform¬ 
ing  an  analysis  of  all  reachable  global  states,  where  a  global  state  is  the  combination  of  all 
states  of  the  component  state  machines  augmented  by  the  current  contents  of  message 
buffers,  if  any.  A  global  state  with  no  exits  is  ei^er  a  deadlock  or  a  desired  termination 
state.  The  process  of  generating  and  analyzing  ail  reachable  global  states  can,  due  to  the 
decidability  of  finite  state  machines,  be  automated  [5, 1 0]. 

Our  approach  does  not  define  states.  Hence,  the  concept  of  "reachable  states"  does  not 
apply.  However,  the  issue  of  detecting  and  avoiding  deadlocks  is  still  relevant.  In  the  context 
of  event  lists,  a  deadlock  is  characterized  by  an  incomplete  event  list,  i.e., "  -•  ls_Complete" 
in  our  model,  that  obeys  the  protocol,  but  for  which  no  correct  extension  exists  except  for 
commands  from  the  operator,  meaning  that  there  is  no  correct  next  communication  event. 

A  communication  protocol  is  said  to  be  complete  if  all  possible  inputs  are  treated.  When 
defining  a  communication  protocol  using  a  state  machine,  the  inputs  refer  to  Information 
received  by  one  of  the  communicating  components  from  either  another  communicating  com¬ 
ponent  or  from  the  external  world.  In  our  model,  the  communicating  components  are  the 
INS  and  the  EC.  Protocol  completeness  in  the  context  of  our  model  means  that  any  ar¬ 
bitrary  input  events  at  the  EC  (e.g.,  INS_Event  or  Signal_from_EC_Operator)  can  be  ap¬ 
pended  to  the  event  list  at  the  EC  without  Protocol_Obeyed_at_EC  being  undefined  and 
similarly  for  EC_Events  and  Protocol_Obeyed_atJNS.  In  that  respect  our  protocol  specifi¬ 
cation  is  complete.  Allowing  all  possible  inputs  is  a  convenient  way  of  capturing  the  be¬ 
havior  of  a  communication  line  that  is  not  error-free,  which  is  the  case  for  [14],  and  it  auto¬ 
matically  ensures  completeness.  Moreover,  due  to  the  fact  that  unexpected  input  is  gener¬ 
ally  ignored  by  the  receiver  according  to  [14],  our  technique  of  removing  such  events  before 
considering  event  histories  provides  a  clean  separation  of  the  treatment  of  normal  and  ab¬ 
normal  cases.  Moreover,  separation  of  the  normal  from  the  abnormal  cases  is  a  well- 
accepted  software  engineering  principle.  Requiring  completeness  in  a  finite  state  model  that 
allows  communication  errors  generally  leads  to  complex  models.  This  appears  to  be  why 
such  models  often  assume  error-free  communication  [6]. 

Protocol  Implementation 

Finite-state  machines  and  programming  language  models  are  fairly  easy  to  turn  Into  imple¬ 
mentations.  A  model  such  as  ours,  without  states,  is  more  abstract  [1]  and  hence  not  direct¬ 
ly  implementable.  One  way  of  implementing  a  protocol  that  has  been  specified  using  our 
approach  is  to  obsen/e  that  some  of  the  Boolean  functions  that  describe  thp  correct  context 
of  an  event  capture  state-like  information  about  the  sequence  of  events  leading  up  to  the 
event  in  question.  That  information  can  be  used  to  build  an  extended  finite-state  model, 
which  can  then  be  implemented  in  a  traditions^  manner.  The  general  reason  for  building  an 
extended  finite-state  machine  instead  of  a  pure  one  is  to  avoid  the  problem  of  state  explo¬ 
sion;  more  specifically,  the  time-related  parts  of  the  protocol  are  better  captured  by  having 
time-variables  and  updating  those  than  by  introducing  additional  states. 
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9.  Suggested  Future  Work 

This  chapter  briefly  discusses  three  ideas  for  continued  work  within  the  area  of  formal  meth¬ 
ods.  Each  idea  involves  using  the  formal  Reification  presented  in  this  report  as  a  starting 
point  in  examining  different  aspects  of  formal  software  development.  The  ideas  focus  on  the 
practical  side  of  using  formal  methods.  Hence,  gaining  experience  with  available  tools  plays 
a  central  role.  The  ideas  involve  examining: 

1.  The  stepwise  development  aspects  of  VDM 

2.  Anna  [19]  and  its  related  tools 

3.  Statemate  [12, 22]  as  a  specification  and  implementation  tool 

9.1.  VDM  and  Stepwise  Development 

The  purpose  of  this  work  is  to  further  examine  VDM.  The  project  has  so  far  only  explored 
formally  specifying  an  existing  natural  language  specification.  This  proposed  activity  will  ex¬ 
amine  the  refinement  method  aspects  of  VDM.  The  idea  is  to  develop  a  system  based  on 
the  formal  specification.  The  development  will  involve  the  design  as  well  as  the  final  imple¬ 
mentation  of  the  system.  Since  the  protocol  has  already  been  implemented  within  the  REST 
Project,  the  suggestion  is  to  develop  a  testing  tool  from  the  formal  specification.  The  formal 
specification  lends  itself  to  this  use  since  it  consists  of  predicates  that  are  true  for  event 
histories  that  obey  the  communication  protocol.  One  would  think  of  a  testing  tool  in  this 
context  as  a  tool  that  would  evaluate  the  data  transmitted  between  the  two  computers  to 
determine  whether  they  are  communicating  properly.  This  would  involve  the  following: 

•  developing  a  formal  specification  in  Meta-IV  for  the  design  of  the  testing  tool 
using  stepwise  refinement 

•  showing  that  the  formal  design  is  a  refinement  of  the  formal  requirements  speci¬ 
fication 

•  implementing  the  testing  tool  in  Ada  from  the  formal  design 

•  applying  the  testing  tool  to  data  acquired  from  the  current  INS  implementation 


9.2.  Anna  and  Its  Tools 

Anna  is  a  language  that  extends  Ada  by  providing  means  for  annotating  Ada  (:>rograms  with 
assertions.  Anna  is  supported  by  a  set  of  tools  including  a  pre-processor  to  an  Ada  compiler 
that  translate  assertions  into  run-time  checks  and  reports  any  violation  of  the  assertions. 
The  Anna  assertions  are  directly  associated  with  the  Ada  code  and  not  any  preceding  speci¬ 
fications.  However,  being  able  to  trace  the  assertions  back  to  an  abstract  specification 
would  Increase  the  value  of  the  assertions  significantly.  The  purpose  of  the  proposed  work  is 
to  examine  Anna  and  its  tool  set  and  Investigate  the  possibilities  oi  systematically  identi¬ 
fying  relevant  Anna  assertions  from  an  abstract  formal  specification.  The  idea  is  to  annotate 
the  current  implementation  of  the  INS  communication  protocol  developed  by  the  REST  Proj¬ 
ect  with  Anna  assertions  that  are  drawn  from  the  formal  specification  presented  in  this  docu¬ 
ment.  This  would  involve: 
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•  drawing  pertinent  assertions  from  the  forms^  specification 

•  annotating  the  INS  implementation  of  the  communications  protocol  with  Anna 
assertions 

•  using  the  Anna  tools  to  perform  run-time  checks  of  the  implementation  of  the 
protocol  to  demonstrate  its  correcness 


9.3.  Statemate  * 

The  purpose  of  this  work  is  to  examine  state-oriented  tools  including  Statemate  [1 2,  22], 
whic  is  a  state-oriented  graphical  formalism,  by  looking  at  the  relationship  between  our 
event-list-based  VDM  formal  specification  and  a  corresponding  state-based  specification.  A 
state  machine  is  a  well-established  way  of  pacifying  and  implementing  communication 
protocols.  Statemate  appears  to  have  an  advanced  set  of  tools  supporting  graphical  specifi-  # 

cation  and  subsequent  implementation  in  Ada.  Given  both  our  model  and  the  Statemate 
tool  set,  the  opportunity  exists  to  address  two  kinds  of  questions;  Is  using  Statemate  a  good 
way  of  implementing  our  protocol  specification?  And,  assuming  that  one  wants  to  use 
Statemate,  is  our  event  list  based  specification  helpful  in  constructing  a  Statemate  specifi¬ 
cation?  The  idea  is  therefore  to  write  a  Statemate  specification  of  the  communication  • 

protocol  based  upon  our  current  specification.  This  would  include; 


•  examining  our  predicates  and  determining  an  appropriate  corresponding  set  of 
states 

•  creating  the  formal  graphical  representation  using  Statemate 

•  simulating  and  generating  the  resulting  implementation 
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